Cibersegurança do operador: 2FA, phishing, levantamentos e proteção do dispositivo
A segurança de uma conta de negociação começa pela conta de email, uma palavra-passe única e um método de autenticação adequado. Também importam os dispositivos, as sessões de acesso, as regras de levantamento e os mecanismos de recuperação se perder o telemóvel. Este artigo explica essas salvaguardas passo a passo, os seus limites e como reagir se suspeitar de uma tomada de controlo da conta. Os utilizadores de VPS e robôs de negociação encontram ainda orientações sobre proteção do acesso remoto, das chaves API e das posições abertas. Abordamos separadamente as burlas que imitam empresas no artigo sobre corretoras falsas.

- O email é a camada 1, não extra opcional. O comprometimento do email pode permitir repor a palavra-passe do corretor e intercetar confirmações de alterações, dependendo dos controlos de recuperação do corretor. Defina uma palavra-passe única para o email e ative a MFA antes de configurar outras camadas.
- Uma única palavra-passe reutilizada pode bastar para tomar o controlo da conta, sobretudo sem MFA eficaz. O credential stuffing, o teste automatizado de pares de nome de utilizador/palavra-passe provenientes de outras violações, visa qualquer palavra-passe reutilizada que tenha sido exposta. Uma palavra-passe única mais 2FA, preferencialmente TOTP em vez de SMS, é o mínimo operacional.
- SMS 2FA supera nenhuma 2FA, mas é inferior a TOTP ou chave física. O SIM swapping pode ser rápido e barato; o tempo, o custo e a taxa de sucesso dependem do operador móvel e do país. TOTP numa aplicação sem cópias das sementes na nuvem, ou uma chave de segurança física como a YubiKey, é um padrão prático.
- O phishing FX pode ser dirigido. Emails falsos de um «corretor», chamadas de um «departamento de segurança» e ligações para páginas de acesso falsas do MT4 podem ser dirigidos especificamente a traders, em vez de enviados inteiramente ao acaso.
- Ative a lista de destinos de levantamento autorizados depois de proteger o email. Se o corretor oferecer uma lista de contas bancárias autorizadas, ative-a: um atacante terá de alterar os dados e passar uma verificação adicional. Essa verificação utiliza frequentemente o email, pelo que oferece proteção limitada se a camada 1 estiver comprometida.
- Um dispositivo para tudo amplia a superfície de ataque. Um dispositivo ou perfil de utilizador separado para negociação é uma questão de disciplina operacional, não uma precaução excessiva.
1. Palavras-passe repetidas: uma fuga ameaça a conta
Comecemos por um cenário muito comum, cuja normalidade é precisamente o que o torna perigoso. Não envolve um pirata informático encapuçado nem a quebra de encriptação. Trata-se de credential stuffing: testar automaticamente, em vários serviços, pares de nome de utilizador/palavra-passe obtidos de violações de bases de dados[1].
O mecanismo é simples. Em 22 de janeiro de 2024, a equipa de investigação da Cybernews descreveu uma coleção acessível ao público com mais de 26 mil milhões de registos e 12 terabytes de dados, apelidada «Mother of All Breaches»[5]. É necessário precisar a sua condição e natureza, porque alteram o significado desse número: não se tratava de uma única violação nova, mas de uma compilação de registos de milhares de violações anteriores e bases de dados transacionadas em privado. O próprio relatório considera os duplicados muito prováveis e trata a presença de informação anteriormente inédita como uma probabilidade, não como uma conclusão demonstrada. O seu relato da exposição posterior é também uma declaração de uma organização, não uma conclusão estabelecida de forma independente: o serviço de pesquisa de violações Leak-Lookup afirmou ser proprietário da coleção e atribuiu a exposição a uma configuração incorreta da firewall que tinha corrigido[5]. Não temos confirmação independente de que as cópias deixaram de circular. Para um trader, a conclusão prática não depende dessa incerteza: se reutilizar uma palavra-passe num fórum de negociação, no Gmail e na conta do corretor, uma dessas milhares de coleções poderá dar a um atacante as credenciais dos três serviços.
A cadeia de ataque possível é: email comprometido → reposição da palavra-passe do corretor → alteração dos contactos → pedido de levantamento para a conta do atacante. O intervalo entre comprometer o email e pedir o levantamento pode ser curto, mas não indicamos uma duração concreta: depende dos procedimentos do corretor para alterar dados e do canal de pagamento, e não encontrámos medições que sustentem um número preciso. O corretor envia a confirmação por email, mas o atacante já controla essa conta.
Modelo por camadas: identifique o que protege
Antes de configurar, defina um modelo de ameaças: o que protege, contra quem e o que acontece se uma determinada camada falhar. Sem esse modelo, pode comprar uma chave física para uma conta cuja recuperação da palavra-passe continua dependente de uma conta antiga de Gmail.
Numa conta de negociação, a cadeia de dependências tem sete elos. Percorra-os por esta ordem:
- Email: a conta a montante. Comprometê-la ameaça a recuperação das outras contas.
- Identidade: o seu número de telefone, códigos de recuperação e documentos que comprovam a sua identidade perante o corretor.
- Dispositivo: o computador e o telemóvel onde introduz segredos e recebe códigos.
- Corretora: a palavra-passe, a MFA, as sessões ativas e as definições do portal do cliente.
- API: chaves programáticas que podem autenticar independentemente de palavra-passe e MFA do portal.
- Pagamentos: os métodos de depósito e levantamento e as listas de contas de destino autorizadas.
- Recuperação: os canais para restaurar o acesso, frequentemente a via alternativa preferida de um atacante.
Regra prática: uma camada depende da que a sustenta. Não se pode confiar na lista de destinos autorizados se o atacante controlar o email que recebe as confirmações das alterações de destino. Por isso, o artigo segue uma ordem deliberada: as secções 1 e 2 abordam email, identidade e corretor; as secções 5 e 6, dispositivos e API; e a secção 4, pagamentos. A recuperação surge ao longo do texto porque oferece uma via alternativa para as outras camadas.
Ações práticas
Use palavra-passe única para a corretora. Não a reutilize noutro local. Utilize um gestor de palavras-passe como Bitwarden, 1Password ou KeePass. Gere uma palavra-passe aleatória com pelo menos 16 caracteres, com margem acima do limiar de 15 caracteres das atuais orientações NIST para palavras-passe usadas como único fator de autenticação[2]. Evite inventar palavras-passe: as pessoas não são boas a gerar aleatoriedade.
Use email separado de trading. Crie uma conta exclusivamente para comunicar com corretores e plataformas de negociação. Não a utilize para registo em fóruns, redes sociais ou outros serviços. Se o seu endereço principal for divulgado, o endereço associado à conta de negociação não ficará exposto através dos mesmos registos. Isso reduz o risco, embora não proteja a conta por si só.
Verifique dados expostos. Introduza o seu email em haveibeenpwned.com e examine que dados foram divulgados. Altere imediatamente uma palavra-passe se foi divulgada, reutilizada ou existirem motivos para suspeitar de comprometimento. Um endereço surgir na violação de outro serviço não demonstra, por si só, que uma palavra-passe diferente e única do corretor tenha sido comprometida.
2. 2FA: mínimo, não opção
A autenticação de dois fatores (2FA) acrescenta uma segunda camada após a palavra-passe. Uma 2FA bem implementada dificulta o início de sessão com uma palavra-passe roubada, mas o phishing pode intercetar códigos, enquanto a recuperação da conta ou o roubo de sessão podem contornar o ecrã normal de acesso. A dificuldade é que os métodos de 2FA não são equivalentes. SMS e TOTP têm fraquezas substancialmente diferentes, tal como tipos distintos de fechadura oferecem proteção diferente.
| Método 2FA | Como funciona | Segurança | Fraqueza principal |
|---|---|---|---|
| SMS | Código único ao telefone | Baixa | SIM swapping: controla o número pelo operador |
| Código ao email | A mais baixa | Se comprometem email, 2FA por email não é independente | |
| TOTP (aplicação autenticadora) | Código gerado localmente a cada 30 segundos (Google Authenticator, Authy); prefira uma configuração sem cópias das sementes na nuvem | Alta | Uma página de phishing pode intercetar um código de utilização única; separadamente, perder o telemóvel sem códigos de recuperação pode deixá-lo sem acesso |
| Chave de segurança física | Dispositivo USB físico (YubiKey, Titan Key) | A mais alta | Exemplo polaco: centenas de PLN conforme modelo e vendedor; suporte limitado |
Porque SMS 2FA não basta
A 2FA por SMS é melhor do que não ter 2FA, mas mais fraca do que TOTP ou uma chave de segurança física. Num SIM swap, um burlão contacta o operador móvel, faz-se passar pelo titular e pede a transferência do número para uma SIM de substituição. Estes ataques podem ser rápidos e baratos, mas o tempo, custo e taxa de sucesso dependem do operador, país e qualidade da informação sobre a vítima. Cada operador define os seus procedimentos de verificação para emitir uma substituição, e os dados utilizados podem estar disponíveis em violações de dados. A escala está documentada nos EUA: a FCC regista no seu Consumer Complaint Center cerca de 300 queixas de SIM swapping e portabilidade em 2020, 400 em 2021 e 500 em 2022[4].
TOTP: padrão prático
TOTP (Time-based One-Time Password) gera códigos localmente no dispositivo a cada 30 segundos. Não utiliza a rede móvel, pelo que o SIM swapping não interceta o código, e a sua geração não exige internet. A ordem de preferência do NCSC britânico coloca os códigos gerados por aplicações bastante acima dos enviados por mensagem[7], embora não sejam a primeira opção. A parte passkeys explica o que supera.
Para configurar TOTP, descarregue uma aplicação autenticadora e escolha a utilização sem conta ou desative a sincronização na nuvem. O Google Authenticator sincroniza códigos com uma conta Google se iniciar sessão e também permite utilização sem conta; o Authy oferece cópias na nuvem. É cómodo, mas o incidente confirmado da LastPass de dezembro de 2022, descrito abaixo, ilustra o ponto de falha adicional criado por guardar material de autenticação na nuvem. Prefira geradores offline com uma cópia física dos códigos de recuperação. Nas definições da conta do corretor, procure «Segurança» → «Autenticação de dois fatores» e leia o QR com a aplicação. O acesso passa a exigir a palavra-passe e o código de 6 dígitos da aplicação.
Crucial: guarde códigos de recuperação. Se o corretor emitir códigos de reserva de utilização única para perda do telemóvel, guarde-os durante a configuração. Caso contrário, verifique e registe o procedimento oficial documentado de recuperação antes de precisar dele. Imprima os códigos e guarde-os em segurança, separados do telemóvel, da conta na nuvem e do gestor de palavras-passe: perder o acesso ao gestor não deve significar perder também os códigos. Uma folha num cofre ou numa gaveta fechada à chave é uma opção.
Passkeys e FIDO2: para onde avançar
A chave é implementação física do padrão mais amplo FIDO2/WebAuthn. Em vez de um código que pode ser ditado a alguém ou copiado numa página falsa, o navegador e o autenticador trocam uma assinatura criptográfica vinculada ao domínio adequado. Outro domínio não consegue obter autenticação para a credencial registada. Essa vinculação ao domínio é a distinção essencial em relação a TOTP.
Uma passkey utiliza este mecanismo com uma credencial FIDO2 guardada num telemóvel, computador ou gestor de palavras-passe e desbloqueada por impressão digital ou PIN do dispositivo, pelo que pode dispensar uma chave separada. O NCSC coloca as credenciais FIDO2 em primeiro lugar na resistência a adivinhação, phishing e roubo de segredos de autenticação. Os códigos gerados por aplicações ocupam o terceiro lugar, e o documento identifica expressamente a sua suscetibilidade a interceção[7]. O NIST permite autenticadores criptográficos multifator nos seus níveis de garantia mais altos quando são cumpridos os requisitos do nível específico; uma passkey sincronizada não se torna automaticamente uma credencial AAL3. A autenticação pela rede telefónica, incluindo SMS, tem estatuto restrito[2].
O que fazer hoje. O suporte a passkeys varia entre corretores de retalho: alguns portais oferecem apenas TOTP e SMS. Procure «chave de segurança», «passkey» ou «WebAuthn» nas definições de segurança. Se suportado, ative-o como método principal e mantenha TOTP como reserva. Se indisponível, TOTP com códigos de recuperação offline continua a ser um mínimo razoável. Ative uma passkey no email independentemente do corretor, pois o email é a camada 1 do modelo acima.
3. Phishing: email, telefone e engenharia social FX
O phishing no forex pode ser dirigido: os atacantes sabem que os traders têm fundos nas contas e reagem a «margin call» e «alerta de segurança». Também pode ser spam comum com o logótipo de um corretor e um domínio registado a baixo custo. Um ataque não precisa de ser sofisticado para funcionar.
Emails falsos de «corretora»
É um vetor de ataque barato e, por isso, comum. Um email imita as cores, o logótipo e o rodapé do corretor. O assunto pode ser «Urgente: verifique a sua conta», «Alerta de segurança: detetado acesso invulgar» ou «Ação necessária: atualize o método de pagamento». A ligação abre uma imitação da página de acesso do corretor noutro domínio. Introduzir as credenciais entrega-as ao atacante. A orientação do NCSC para organizações aborda dois elementos: a falsificação do remetente, combatida por DMARC, SPF e DKIM, e a necessidade de uma via simples e rápida para comunicar mensagens suspeitas[6]. Não trata domínios parecidos; o seguinte é explicação nossa, não atribuída ao NCSC.

Chamadas da «segurança»
Um método mais elaborado é o vishing, ou phishing por voz. Alguém liga afirmando trabalhar na segurança do corretor, diz ter detetado atividade suspeita e pede uma verificação de identidade: «Diga-me o número da conta e o código de 2FA que acabámos de enviar». Facultá-lo pode autorizar o acesso do atacante.
Uma corretora correta não deve pedir 2FA de acesso pelo telefone. Quem o pede pode estar a comprometer a conta em vez de a proteger. Desligue e ligue para o número oficial do sítio do corretor, não o do email. A pressão para agir depressa pode ser mais eficaz do que malware.
Descargas MT4/MT5 falsas
Os traders procuram no Google «MT4 download» ou «MT5 download». Os atacantes podem comprar anúncios para instaladores modificados: parecem familiares e podem funcionar normalmente enquanto enviam credenciais para um servidor controlado pelo atacante. Uma página falsa de descargas distribui malware eficazmente porque o utilizador executa o instalador e lhe concede permissões.
Engenharia social em grupos
Os grupos de negociação no Telegram, Discord e Facebook oferecem oportunidades de engenharia social. Um suposto administrador envia uma mensagem privada: «Tenho uma oferta especial do corretor X, mas tem de se registar pela minha ligação». Ou: «Publique uma captura da conta e ajudo a configurar o seu EA». Uma captura pode revelar o número da conta do corretor, ajudando um atacante a manipular verificações telefónicas de identidade fracas. Compreenda essa exposição antes de publicar o «lucro do dia» num grupo.
4. Levantamentos seguros: métodos, listas e documentos KYC
Um atacante que tome o controlo da conta pode fechar posições e prejudicar o capital, mas desviar fundos torna-se mais difícil com uma lista eficaz de destinos autorizados. O controlo visa enviar fundos para uma conta já aprovada em seu nome. Configurar levantamentos é uma questão de segurança, além de comodidade.
Lista de contas autorizadas
Se o corretor oferecer «Destinos de levantamento aprovados» ou uma «Lista de levantamentos autorizados», verifique as regras exatas. Ativá-la restringe os levantamentos a contas bancárias previamente aprovadas. Adicionar uma conta pode exigir verificação adicional e espera; o corretor determina a disponibilidade e duração desses controlos. Dificulta o desvio, mas não garante parar um levantamento após a tomada de controlo.
Verifique se o corretor suporta listas de destinos autorizados e ative-as se disponíveis. Procure «Lista de levantamentos autorizados», «Destinos aprovados» ou «Contas de confiança» no portal do cliente. Verifique o contrato e as definições de segurança: a disponibilidade muda e pode diferir entre entidades do mesmo grupo. Considere a ausência uma desvantagem ao comparar controlos, não uma prova conclusiva de desonestidade.
Notificações de levantamento
Ative email e notificações push para cada pedido de levantamento. Se vir um que não apresentou, ligue imediatamente ao corretor: o email pode estar comprometido. Costuma existir tempo de processamento entre pedido e execução pelo corretor e pelo banco, mas a duração depende dos termos da entidade concreta. Verifique-os antes, não durante o incidente. Essa janela oferece frequentemente a melhor oportunidade de parar uma transferência, mas não é a única: após o envio, o banco ou prestador de pagamentos pode iniciar uma recuperação, como explicado abaixo.
Alterações de dados: ponto crítico
O evento crítico é frequentemente alterar o email, telefone, conta bancária ou beneficiário do levantamento, não o acesso em si. Mudar os métodos semanalmente pode desencadear uma revisão manual de conformidade e, por vezes, uma restrição temporária precisamente quando quer levantar lucros. Escolha um método adequado, verifique-o e utilize-o de forma consistente.
Documentos KYC: podem abrir outra conta
Para abrir uma conta, envia ao corretor uma digitalização do cartão de identidade ou passaporte, um comprovativo de morada e, por vezes, um extrato bancário. Em conjunto, esses documentos podem facilitar a abertura ou recuperação de outra conta. Trate-os como informação sensível de identidade, não como um anexo corrente.
Na prática, carregue documentos pelo portal, em vez de email ou aplicações de mensagens. Se um email os pedir, ligue para o número do sítio verificado para confirmar o pedido. Não deixe cópias em descargas ou galeria; se guardar use contentor cifrado ou gestor com anexos. Elimine cópias de trabalho após verificar, incluindo mensagens enviadas e conversas. Um documento divulgado pode facilitar uma tentativa de recuperação com «esqueci a palavra-passe e perdi a 2FA». Se disponível, defina previamente uma palavra-passe para contacto telefónico. Perguntas como o apelido de solteira da mãe ou a primeira escola são outra questão: as respostas podem ser reconstruídas a partir de violações de dados e redes sociais. Se o corretor as utilizar, trate-as como verificação complementar a MFA forte e recuperação verificada, não como substituto.
5. Dispositivos: VPN, Wi-Fi público, atualizações e separação
O computador e o telemóvel são portas de acesso à conta de negociação. Se um dispositivo estiver comprometido, palavra-passe, 2FA e lista autorizada em conjunto podem continuar a ser insuficientes: o atacante pode potencialmente observar o que faz no ecrã.
Wi-Fi público: o que resolve VPN e o que não
Distinga as medidas essenciais dos controlos adicionais, porque o Wi-Fi público suscita muitos exageros. O essencial é HTTPS corretamente verificado, endereço do portal introduzido manualmente no domínio certo, não ignorar avisos de certificado, dispositivo atualizado e MFA resistente ao phishing. A autoridade de proteção do consumidor dos EUA afirma expressamente que a encriptação generalizada costuma tornar seguras as ligações por Wi-Fi público[13]. Também refere que burlões podem obter certificados para os seus sítios, pelo que a encriptação, por si só, não identifica o destinatário da informação.
O Wi-Fi público continua a apresentar riscos de hotspots falsos, redirecionamento para páginas de acesso imitadas e phishing. Uma VPN ou um hotspot próprio é camada adicional, não um pré-requisito de segurança. Pode reduzir a exposição do tráfego auxiliar e a dependência de uma rede desconhecida, mas não reparar um dispositivo infetado nem impedir que introduza uma palavra-passe num domínio falso.
Se escolher uma VPN, selecione um fornecedor com política clara de registos e verifique como se financia. Num serviço gratuito, isso importa mais do que o preço: alguns planos gratuitos são financiados por subscrições pagas, outros monetizam tráfego e dados dos utilizadores. Avalie o modelo de negócio, política de registos e auditoria independente do fornecedor específico, sem pressupor que pagar demonstra fiabilidade. A partilha LTE/5G do seu telemóvel é frequentemente mais simples e evita acrescentar outro fornecedor em quem confiar.
Camadas de segurança, como uma VPN ou análises num VPS, podem afetar a latência de rede ou a carga do dispositivo. Meça o efeito na sua configuração. O artigo sobre infraestrutura de execução explica quando isso importa, por exemplo na negociação de notícias ou no scalping e quando não.
Sessões ativas: revisão e revogação
O acesso cria uma sessão que pode permanecer ativa no navegador, aplicação móvel ou terminal. Malware que roube cookies de sessão pode não precisar da palavra-passe nem do código de 2FA: uma sessão válida pode bastar. Alterar a palavra-passe após um incidente sem revogar sessões pode, por isso, deixar o atacante ligado.
Procure «Sessões ativas», «Dispositivos», «Dispositivos ligados» ou «Atividade de segurança» no portal. Reveja a lista periodicamente e termine o que não reconhece: outro computador, um telemóvel antigo ou um local desconhecido. Se existir «Terminar sessão em todos os dispositivos», saiba onde está antes de um incidente. Faça o mesmo no email associado ao corretor, a camada 1 do modelo acima.
Separação de dispositivos
Gere capital: mantenha limpo o ambiente. Um dispositivo dedicado é um portátil ou tablet no qual evita navegação alheia à negociação, anexos e software não verificado. As ferramentas necessárias são a plataforma, um navegador para o portal do corretor e um gestor de palavras-passe.
No exemplo orçamental polaco, um ThinkPad recondicionado de cerca de mil PLN pode ser uma opção para proteger a conta. Se outro dispositivo for impraticável, um perfil de utilizador separado no sistema operativo ajuda a organizar e reduz alguma exposição, mas não substitui um dispositivo separado perante malware mais grave.
Atualizações: rotineiras e críticas
Windows, macOS, Android, iOS, MT5 e cTrader recebem atualizações, incluindo correções de segurança; MT4 é abordado separadamente abaixo. Uma instalação desatualizada pode conter vulnerabilidades conhecidas exploráveis. Ative atualizações automáticas em vez de as adiar indefinidamente.
MetaTrader 4 continua a receber atualizações do fabricante. Não atribuímos à MetaQuotes um fim formal do desenvolvimento de MT4, pois não encontrámos um anúncio do fabricante que o estabeleça. Se usar MT4, confirme que tem a versão mais recente do corretor ou fabricante. Versões antigas de sítios alheios podem conter vulnerabilidades conhecidas.
6. Segurança VPS/EA: operações órfãs e acesso remoto
Executar Expert Advisors (EA) num VPS introduz uma superfície de ataque adicional. Esse computador remoto opera 24/7, permanece ligado ao corretor e pode aceder à conta de negociação. Comprometê-lo pode dar ao atacante o controlo do ambiente de negociação.
Configuração RDP segura
Remote Desktop Protocol (RDP) é uma forma habitual de ligação a um VPS Windows. RDP exposto diretamente à internet é um alvo persistente: bots de pesquisa tentam ataques às palavras-passe continuamente, 24/7.
Mudar porta só protege pouco. Priorize não expor RDP publicamente, acesso por túnel VPN/WireGuard; uma lista IP autorizada se o prestador dá endereço estável; autenticação de nível de rede (NLA); MFA no prestador VPS e à parte no gateway se usado; e instantâneos regulares e registo de eventos. Aplique o princípio do privilégio mínimo: instale apenas o que o ambiente de negociação necessita.
Controle palavras-passe MT4/MT5 no VPS
MT4 e MT5 oferecem «Guardar palavra-passe» ao iniciar sessão. Desative se desnecessário ao funcionamento previsto: credenciais guardadas facilitam o acesso após comprometer o anfitrião ou a sessão. Para um EA 24/7, verifique como o terminal volta a ligar após reiniciar. Desativar o armazenamento sem plano de reautenticação pode parar a automatização.
Isto difere de guardar a palavra-passe num gestor. Um gestor encripta o segredo com a sua própria autenticação e pode integrar uma configuração EA 24/7 quando o anfitrião e a via de acesso estão protegidos por MFA e lista de IP autorizados. A ordem é proteger primeiro o anfitrião e o acesso e depois decidir como fornecer as credenciais. Nenhuma medida substitui a outra: limite armazenamento e permissões às necessidades da automatização; introduzir manualmente a palavra-passe não justifica RDP público com configuração predefinida.
Operações órfãs: sem controlador
Uma operação órfã foi aberta por um EA, mas deixa de ser gerida após falha do VPS, perda de ligação ou reinício. Pode não ter stop-loss, porque o algoritmo devia gerir a saída dinamicamente, nem take profit nem alguém a vigiá-la. A posição pode permanecer exposta até uma chamada de margem ou outra intervenção.
Salvaguarda: um EA deve definir um stop loss aceite no servidor em vez de depender apenas de um stop virtual algorítmico. Se o EA parar, o SL aceite permanece no servidor, mas não garante o preço de execução nem uma perda limitada ao montante previsto. O compromisso importa: com pouca liquidez e um amplo spread, como na janela de rollover do corretor, um stop pode ser acionado em condições piores do que o esperado. Para um rollover às 17:00 de Nova Iorque, o exemplo polaco é geralmente às 23:00, ou às 22:00 quando as mudanças de hora de verão não coincidem. Isso não prova, por si só, que o corretor visou o seu stop. Um stop virtual oculta o nível fixo no terminal, mas acrescenta dependência de infraestrutura. Escolha de acordo com as condições de execução do corretor e o método de negociação.
Não partilhe VPS
Partilhar um VPS para poupar pode expor EA e posições abertas a outro utilizador com potencial acesso ao terminal, ficheiros, registos e segredos. No exemplo polaco, poupar PLN 50 cria essa exposição. Mantenha o VPS sob controlo de um único trader, em vez de partilhar o ambiente da conta com utilizadores alheios.
Contas maiores e negociação algorítmica podem utilizar API FIX ou colocation perto dos servidores do corretor, abordadas em infraestrutura de execução. Aplica-se a mesma distinção de segurança das outras chaves API: distinguir credenciais apenas de leitura das autorizadas a colocar ordens.
7. Lista de verificação de 10 minutos e resposta a incidentes
Hoje pode aceder às posições abertas e amanhã perder esse acesso. O que se segue destina-se a uma revisão de 10 minutos: suficiente para percorrer a lista e identificar os pontos que ainda não pode assinalar como concluídos.
| # | Elemento | Padrão mínimo | Estado |
|---|---|---|---|
| 1 | Email protegido de forma independente | Palavra-passe única do email, MFA (preferencialmente uma passkey), regras de reencaminhamento e filtros revistos: camada 1 da secção 1 | ☐ |
| 2 | Email separado para negociação | Endereço dedicado não utilizado para registo noutros serviços | ☐ |
| 3 | Palavra-passe única do corretor | 16+ caracteres aleatórios de um gestor de palavras-passe, nunca reutilizados noutro local | ☐ |
| 4 | 2FA ativada (TOTP) | Aplicação TOTP sem cópia na nuvem, em vez de SMS ou email | ☐ |
| 5 | Códigos de recuperação de 2FA offline | Impressos e guardados num local seguro | ☐ |
| 6 | Destinos de levantamento autorizados | Se suportado: apenas contas bancárias aprovadas, com regras verificadas para alterar o destinatário | ☐ |
| 7 | Notificações de levantamento | Notificações por email e push para cada pedido de levantamento | ☐ |
| 8 | Atualizações do sistema e da plataforma | Atualizações automáticas ativadas; versões atuais do MT4/MT5 | ☐ |
| 9 | Redes desconhecidas: HTTPS verificado, VPN como camada adicional | Introduzir manualmente o endereço do portal; nunca ignorar avisos de certificado. Uma VPN com política de registos verificada ou a partilha de ligação do telemóvel são medidas complementares | ☐ |
| 10 | Dispositivos ou perfis separados | Computador ou perfil de utilizador para negociação separado da atividade quotidiana | ☐ |
| 11 | VPS: túnel VPN, lista de IP autorizados e MFA do fornecedor | Sem RDP público; acesso por VPN/WireGuard, lista de IP autorizados, MFA do fornecedor e MFA independente do gateway, se utilizado | ☐ |
| 12 | VPS: segredos controlados e restritos | Armazenamento de credenciais do terminal limitado às necessidades de automatização; início de sessão após reinício testado, gestor de palavras-passe e anfitrião e acesso protegidos | ☐ |
| 13 | EA: SL no servidor em caso de falha do VPS | SL aceite pelo servidor do corretor, em vez de apenas um stop virtual do EA | ☐ |
| 14 | Revisão das sessões ativas | Listas de dispositivos do corretor e do email revistas; sessões desconhecidas terminadas | ☐ |
| 15 | Chaves API não utilizadas revogadas | Chaves não utilizadas revogadas; permissões restantes reduzidas e restrições de IP aplicadas quando suportadas | ☐ |
| 16 | Canais de contacto verificados do corretor guardados | Número de telefone oficial, portal e endereço de conformidade registados fora da conta de email | ☐ |
| 17 | Sem acesso remoto para pessoas não verificadas | Sem AnyDesk, TeamViewer nem partilha de ecrã a pedido de um «consultor», «departamento de segurança» ou «empresa de recuperação» que contacte sem solicitação prévia | ☐ |
Cliquei numa ligação, introduzi a palavra-passe e aprovei a MFA: e agora?
É um cenário difícil porque o segundo fator não falhou tecnicamente: foi aprovado por si. O atacante pode ter agora uma sessão válida e permissão para alterar dados. A ordem das ações importa, não apenas a rapidez de uma ação isolada. Utilize outro dispositivo de confiança e deixe de interagir com o email suspeito.
- Revogue as sessões além de alterar a palavra-passe. Termine as sessões de todos os dispositivos no portal do corretor e depois altere a palavra-passe. Alterá-la nem sempre encerra as sessões. Se não existir um controlo para o fazer, informe expressamente a linha de apoio do corretor.
- Proteja o email. Altere a palavra-passe, termine as sessões e examine as regras de reencaminhamento e os filtros. Uma regra que mova mensagens do corretor para o lixo pode ocultar a tomada de controlo.
- Ligue ao corretor para o número guardado previamente, em vez de utilizar um número da mensagem. Peça a suspensão dos levantamentos e a sinalização da suspeita de comprometimento. Pergunte se os contactos ou destinos de levantamento foram alterados nas últimas horas.
- Reponha o segundo fator. Revogue a credencial afetada e configure novamente a MFA. Gere novos códigos de recuperação e invalide o conjunto antigo.
- Revogue as chaves API e verifique se foram criadas novas chaves. Uma chave autorizada a negociar pode continuar válida após alterar a palavra-passe.
- Verifique os dados de levantamento e a lista de destinos autorizados. Comunique uma conta desconhecida como parte do mesmo incidente, não como uma questão administrativa separada.
- Documente tudo. Guarde capturas datadas, o email com os cabeçalhos completos, o histórico de acessos e o número de referência da linha de apoio. Estes elementos apoiam uma reclamação ou um posterior litígio com o corretor.
- Verifique o dispositivo. Se também suspeitar de malware, por exemplo devido a janelas ou extensões desconhecidas ou lentidão inexplicável, utilize um dispositivo limpo até a situação ser investigada, como explicado na secção 5.
- Comunique a ocorrência. Participe um levantamento não autorizado à polícia e ao supervisor do corretor. No exemplo polaco, comunique separadamente o incidente técnico, incluindo phishing, email comprometido ou dispositivo comprometido, ao CERT Polska através de incydent.cert.pl[14]. Este canal técnico não substitui a participação criminal nem a reclamação ao corretor e não determina o reembolso. Fora da Polónia, utilize o canal nacional adequado para comunicar incidentes. O artigo 13.7 explica a distinção entre reclamação e atuação de supervisão, bem como as vias processuais pertinentes.
O que não fazer: não instale software para «verificar o computador» enviado por alguém que ligou sem solicitação prévia, não conceda acesso remoto nem deposite mais dinheiro para «desbloquear um levantamento». Cada pedido indica uma possível segunda fase do mesmo ataque.
Esta lista não protege contra perdas de mercado. Destina-se a reduzir o risco de perder o controlo da conta por razões alheias ao mercado, muitas das quais podem ser tratadas com uma configuração cuidada.
Perguntas frequentes: cibersegurança do trader de forex
A 2FA por SMS basta para proteger uma conta de corretagem?
O que fazer se perder o telemóvel com a aplicação de 2FA?
Devo utilizar uma VPN para negociar?
Como proteger o MT4/MT5 no telemóvel?
O que fazer se suspeitar de acesso não autorizado à conta?
Um EA pode roubar as minhas credenciais?
Fontes
- OWASP Foundation, «Credential Stuffing Prevention Cheat Sheet», cheatsheetseries.owasp.org/cheatsheets/Credential_Stuffing_Prevention_Cheat_Sheet.html: define o teste de pares de nome de utilizador/palavra-passe provenientes da violação de outro serviço e descreve controlos do serviço, incluindo MFA, restrições de IP e deteção de dispositivos ou endereços desconhecidos. Não mede a proporção de tomadas de controlo de contas de corretagem atribuível a este vetor; não lhe é atribuída aqui tal estatística. Consultado em 31 de agosto de 2026.
- National Institute of Standards and Technology (NIST), «Digital Identity Guidelines — SP 800-63B-4», pages.nist.gov/800-63-4/sp800-63b/authenticators/: secção 3.1.1.2: pelo menos 15 caracteres quando a palavra-passe é o único fator, ou 8 no âmbito de MFA; secção 3.1.3.3: a autenticação pela rede telefónica pública, incluindo SMS, é restrita, sendo exigida uma alternativa; a secção 3.1.7 abrange autenticadores criptográficos multifator. A edição SP 800-63B de 2 de março de 2020 anteriormente citada aqui foi substituída pela SP 800-63B-4, finalizada em 31 de julho de 2025, cuja numeração de secções se aplica acima. Não abrevie este identificador para «SP 800-63-4»: esse documento geral separado substituiu a SP 800-63-3, e não a SP 800-63B. Estado do documento verificado em csrc.nist.gov/pubs/sp/800/63/b/4/final. Consultado em 1 de setembro de 2026.
- Financial Conduct Authority, «PS26/2: Operational incident and third party reporting», fca.org.uk/publications/policy-statements/ps26-2-operational-incident-third-party-reporting: declaração de política publicada em 18 de março de 2026: definição de incidente operacional, limiares de comunicação e processo normalizado; separadamente, comunicação de acordos relevantes com terceiros e registo anual. Está prevista a aplicação das regras resultantes a partir de 18 de março de 2027. Substitui a referência desatualizada do artigo anterior a meros «requisitos anunciados de comunicação de incidentes». Consultado em 31 de agosto de 2026.
- Federal Communications Commission, «Protecting Consumers from SIM Swap and Port-Out Fraud», Report and Order and Further Notice of Proposed Rulemaking, FCC 23-95, WC Docket No. 21-341, docs.fcc.gov/public/attachments/FCC-23-95A1.pdf: adotado em 15 de novembro de 2023 e publicado em 16 de novembro de 2023. As cerca de 300 queixas em 2020, 400 em 2021 e 500 em 2022 relativas a SIM swapping e portabilidade fraudulenta provêm da nota 13 e dos registos do Consumer Complaint Center da Comissão. Consultado em 31 de agosto de 2026 (98 páginas; texto extraído localmente na auditoria polaca original).
- Vilius Petkauskas, Cybernews, «Mother of all breaches reveals 26 billion records: what we know so far», cybernews.com/security/billions-passwords-credentials-leaked-mother-of-all-breaches/: publicado em 22 de janeiro de 2024; material atualizado, com 15 de junho de 2026 registado como última atualização na auditoria polaca das fontes. A coleção de 12 TB continha mais de 26 mil milhões de registos em cerca de 3.800 diretórios, descrita como provavelmente a maior compilação de múltiplas violações (COMB), com duplicados muito prováveis. Trata-se de informação secundária sobre as violações subjacentes e assim é tratada: sustenta a descrição da compilação, não conclusões sobre cada violação que a integra. Consultado em 31 de agosto de 2026.
- National Cyber Security Centre (NCSC UK), «Phishing attacks: defending your organisation», ncsc.gov.uk/guidance/phishing: controlos DMARC, SPF e DKIM contra falsificação do remetente, uma política de quarentena ou rejeição e uma via simples para comunicar prontamente mensagens suspeitas. A auditoria original verificou separadamente o seu âmbito: não aborda domínios de aspeto semelhante, pelo que esse tema não lhe é atribuído. Consultado em 31 de agosto de 2026.
- National Cyber Security Centre (NCSC UK), «Recommended types of MFA», em «Multi-factor authentication for your corporate online services», ncsc.gov.uk/collection/mfa-for-your-corporate-online-services/recommended-types-of-mfa: ordem de preferência: 1) credenciais FIDO2, 2) aplicações baseadas em desafios, 3) geradores de códigos em aplicações (TOTP), 4) geradores físicos de códigos, 5) códigos enviados por mensagem. Consultado em 31 de agosto de 2026.
- MetaQuotes, «The checks a trading robot must pass before publication in the Market», mql5.com/en/articles/2555, 1 de agosto de 2016: verificações obrigatórias antes da publicação no MQL5 Market e proibição de importações de DLL e de ficheiros EX4/EX5 compilados nos produtos do Market. Consultado em 31 de agosto de 2026.
- LastPass, «Notice of Security Incident», blog.lastpass.com/posts/notice-of-recent-security-incident: aviso de 22 de dezembro de 2022 que confirma a cópia de cópias de segurança de dados dos clientes, incluindo cofres de palavras-passe. Os campos sensíveis, como nomes de utilizador, palavras-passe e notas, estavam encriptados; alguns metadados, incluindo URL de sítios, não estavam. Consultado em 31 de agosto de 2026; o aviso histórico original foi verificado novamente em 9 de outubro de 2026.
- Banco Nacional Suíço, «Swiss National Bank discontinues minimum exchange rate and lowers interest rate to -0.75%», snb.ch/en/publications/communication/press-releases/2015/pre_20150115, 15 de janeiro de 2015: fonte da decisão e da respetiva data. A página não especifica a hora de publicação; o comunicado completo está disponível em PDF para descarregar. Consultado em 31 de agosto de 2026.
- Regulamento (UE) 2022/2554 do Parlamento Europeu e do Conselho, de 14 de dezembro de 2022, relativo à resiliência operacional digital do setor financeiro (DORA), CELEX 32022R2554, JO UE L 333, 27.12.2022: gestão do risco de TIC e comunicação de incidentes graves relacionados com TIC pelas entidades financeiras abrangidas. O artigo 2(1) está sujeito aos números 3 e 4 e inclui «empresas de investimento» na alínea (e); o artigo 2(3)(d) isenta pessoas abrangidas pelas isenções dos artigos 2 e 3 da Diretiva 2014/65/UE. O texto polaco utilizado na auditoria original foi obtido através de publications.europa.eu/resource/celex/32022R2554; o cabeçalho identifica «27.12.2022 PL Official Journal of the European Union L 333/1». As disposições finais fixam expressamente a aplicação a partir de 17 de janeiro de 2025 e a entrada em vigor no vigésimo dia após a publicação no Jornal Oficial. A publicação em 27 de dezembro de 2022 resulta, portanto, em 16 de janeiro de 2023; o ato não indica numericamente esta última data. Consultado em 1 de setembro de 2026.
- MetaQuotes, documentação de referência MQL5, «FileOpen» (mql5.com/en/docs/files/fileopen) e «WebRequest» (mql5.com/en/docs/network/webrequest): as operações de ficheiros estão restritas à sandbox de ficheiros e WebRequest exige inserir o URL do servidor na lista de URL permitidos em «Expert Advisors», dentro de «Options». A documentação afirma: «Os ficheiros sobre os quais são realizadas operações através de MQL5 não podem estar fora da sandbox de ficheiros». Consultado em 31 de agosto de 2026. O contexto de execução de DLL foi adicionalmente verificado em «About Dynamic-Link Libraries» da Microsoft, learn.microsoft.com/en-us/windows/win32/dlls/about-dynamic-link-libraries, em 9 de outubro de 2026.
- Federal Trade Commission, «Are Public Wi-Fi Networks Safe? What You Need To Know», consumer.ftc.gov/articles/are-public-wi-fi-networks-safe-what-you-need-know, fevereiro de 2023: a encriptação generalizada costuma tornar seguras as ligações Wi-Fi públicas, mas os burlões também podem encriptar sítios falsos. A encriptação, por si só, não demonstra quem recebe a informação. Consultado em 31 de agosto de 2026.
- Exemplo prático polaco: o CERT Polska funciona no NASK, o instituto nacional de investigação, e desempenha funções de CSIRT NASK como uma das três equipas polacas de resposta a nível nacional (cert.pl/o-nas). O formulário de incidentes está em incydent.cert.pl, com o título «Zgłoś incydent | CERT.PL». É citado exclusivamente como canal de comunicação de incidentes técnicos: esta fonte não estabelece um processo de reclamação financeira nem uma decisão de reembolso. Fora da Polónia, utilize o canal nacional pertinente. Consultado em 1 de setembro de 2026.