Acesso remoto. Scripts em massa. Automação em escala.
Nas mãos erradas, um RMM não é uma ferramenta de suporte. É uma arma. O termo tem nome: LOLRMM (Living Off the Land RMM). Um atacante instala um agente legítimo, usa ele pra executar scripts, se mover pela rede e manter persistência — sem malware próprio, sem assinaturas pra detectar, sem que nada pareça obviamente errado.
Olha, o Lunixar foi construído pra evitar exatamente isso. De fora e de dentro.
O que um RMM pode fazer quando não tem controle
Um agente RMM num endpoint tem acesso real: executar comandos, baixar arquivos, abrir sessões remotas, criar usuários locais. Se alguém usa esse acesso com má intenção, o estrago tá feito antes de qualquer alerta disparar.
Os vetores mais usados em ataques LOLRMM:
- Baixar e executar payloads da internet:
curl,wget,iwr,irm | iex - Criar persistência: serviços do Windows, tarefas agendadas, chaves Run/RunOnce do registro, usuários locais com admin
- Túneis reversos pra manter acesso mesmo se a porta do RMM for bloqueada
- Instalar outros agentes em silêncio — AnyDesk, ScreenConnect, MeshAgent, TacticalRMM
O cenário mais perigoso não é um hacker de fora. É um tenant que se cadastra com dados falsos e começa a operar como se fosse legítimo.
Dica prática: se o seu RMM não controla o que um tenant pode executar, qualquer conta comprometida é uma porta aberta pra toda a frota.
Política de conteúdo: o que o Lunixar bloqueia por padrão
Tenants sem confiança verificada têm restrições automáticas sobre execução remota. O Lunixar bloqueia combinações de download e execução em scripts, terminal e agendamentos:
Invoke-WebRequest/iwr,Invoke-RestMethod/irmcurl,wget,Start-BitsTransfer,bitsadmin,certutilStart-Process,msiexec,cmd /cInvoke-Expression/iex,wscript,cscript,rundll32,regsvr32- Qualquer indicador HTTP/HTTPS em scripts combinado com execução
O padrão irm https://... | iex — queridinho dos instaladores maliciosos em PowerShell — é bloqueado de forma específica. Scripts que combinam download remoto e execução são salvos com IsMalicious = true. As execuções bloqueadas ficam no log com WasBlockedBySecurityPolicy e o motivo exato da política.
As regras de destinos bloqueados são gerenciadas pelo painel de administração da plataforma e aplicadas em cadastro de contas, terminal interativo, scripts salvos, agendamentos e execução via WebSocket.
Dica prática: tenants com confiança verificada podem ser habilitados por no máximo 30 dias, com motivo de aprovação registrado e auditoria completa. O acesso vence — não renova automaticamente.
Níveis de confiança: todo tenant começa restrito
O Lunixar não confia em nenhum tenant por padrão. Dá pra entender os cinco estados assim:
| Estado | O que significa |
|---|---|
trial | Instância de teste. Um instalador ativo por plataforma, máximo 5 usos, validade de 3 dias. |
unverified | Conta ativa, identidade não verificada. Sem terminal livre, sem scripts personalizados, sem execução agendada em massa. |
verified | Identidade verificada. Operação normal com auditoria ativa. |
trusted | Confiança estendida pra execução remota completa, concedida pelo admin da plataforma, TTL máximo de 30 dias. |
restricted | Sancionado. Terminal, scripts, agendamentos e sessões de viewer bloqueados. Isolamento e dados do tenant preservados. |
blocked | Totalmente bloqueado. Login e dispatch parados. |
Tokens de enroll têm expiração e limite de usos. Tokens comprometidos são revogados sem afetar o resto do tenant. Os instaladores de agente também mantêm um nome controlado pelo Lunixar e não podem ser renomeados pela plataforma, reduzindo o risco de arquivos disfarçados.
Dica prática: quando um tenant vai pra restricted, a operação básica de suporte continua ativa. Só a execução remota sensível é cortada.
Detecção e auditoria: tudo deixa rastro
Se um tenant começa a se comportar como vetor de ataque, o Lunixar detecta e escala:
- Scripts e comandos bloqueados por política são auditados em
script_logscom razão e timestamp - A pontuação de abuso do tenant é calculada com sinais: muitos instaladores gerados, muitos endpoints enrollados rápido, comandos bloqueados com frequência, geografias ou ASNs suspeitos, redes residenciais
- Casos que cruzam o limite entram automaticamente na fila interna de operações de abuso
- O kill switch da plataforma cobre o ciclo completo: bloquear o tenant → revogar instaladores e tokens ativos → cortar sessões SignalR ativas → parar o dispatch pendente → marcar agentes pra quarentena
Mudanças no nível de confiança têm timestamp, usuário que as fez e motivo opcional. Tenants suspeitos podem entrar no modo de auditoria de alta retenção — mais evidências de scripts, terminal, instaladores, enrolls e sessões de viewer, guardadas por mais tempo.
Dica prática: o histórico de bloqueios por política é um dos sinais mais limpos de abuso intencional. Muitos bloqueios em pouco tempo, mesmo tenant, mesmo tipo de script — isso já é um padrão pra investigar.
Catálogo de ferramentas e detecção de persistência
Tipo assim: o Lunixar mantém um catálogo de ferramentas RMM conhecidas — AnyDesk, ScreenConnect, MeshAgent, Atera, TeamViewer, TacticalRMM, UltraVNC, NetSupport, e mais. Se um script ou processo tenta instalar ou ativar qualquer uma delas, é classificado e bloqueado conforme o nível de confiança do tenant.
A detecção de persistência cobre os padrões mais usados em ataques LOLRMM:
- Serviços do Windows e tarefas agendadas
- Chaves de registro Run e RunOnce
- Usuários locais com privilégios de administrador
- Exceções de firewall não autorizadas
- Túneis reversos
- Unidades systemd e cron jobs no Linux
Pra tenants não verificados, qualquer script que tente criar persistência é bloqueado antes de chegar ao agente. O modo de allowlist por tenant permite declarar os domínios e binários legítimos da sua organização — o resto é bloqueado por padrão.
Dica prática: se você usa ferramentas de acesso remoto adicionais com seus clientes, declare os domínios delas no allowlist do tenant. Sem isso, instaladores de terceiros podem acabar bloqueados.
---
LOLRMM não é um risco teórico. Atacantes já estão usando plataformas RMM legítimas como vetor de ataque — e as plataformas sem controles internos são as primeiras a ser exploradas. O Lunixar foi construído desde o início pra não ser esse vetor: política de conteúdo, níveis de confiança, auditoria completa e detecção ativa de persistência.
