Kiosk Escape no Windows: metodologia, comandos e hardening

Resumo:

• Um kiosk escape seguro exige restrição do sistema operacional e do ambiente físico, pois o pentest deve ir além da interface visual e testar atalhos, file pickers, periféricos, arquivos locais e rede.
• O teste deve ser planejado com limites claros e regras de parada, alinhando permissões de periféricos, acessos de rede e o mascaramento de evidências sensíveis em dados sintéticos.
• A avaliação técnica se inicia descobrindo o mecanismo real de restrição (Assigned Access, Shell Launcher, AppLocker) e registrando o contexto e os privilégios da conta local.
• A execução combina uma matriz de tentativas de escape (file pickers, impressão, falhas), checagem do AppLocker, varredura de segredos em arquivos de configuração e busca por diretórios graváveis com prova mínima.
• O escopo final valida a exposição da rede sem varreduras indiscriminadas, a segurança do navegador e das APIs do backend, além do comportamento do terminal após erros, reinicializações e quedas de conexão.

Um kiosk seguro não é apenas uma aplicação em tela cheia. A arquitetura dedicada garante que o usuário físico fique restrito à experiência prevista, mesmo se tentar abrir diálogos, forçar erros, usar atalhos, conectar periféricos ou alcançar o sistema operacional. 

Para um pentester, o trabalho combina testes manuais de escape, análise do contexto local obtido, verificação das políticas efetivas do Windows, revisão de arquivos e segredos, validação da conectividade de rede e análise da aplicação e das APIs consumidas pelo terminal.

Defina o objetivo e a regra de parada antes de testar

Os Kiosks costumam estar ligados a operações críticas. Antes do teste, documente o que pode ser explorado e até onde o pentester pode avançar depois de um escape. Em muitos projetos, provar que a interface restrita permite abrir um terminal com a identidade do kiosk já é evidência suficiente. Em outros, o escopo permite demonstrar acesso a arquivos, conectividade ou recursos internos específicos.

• Confirme o modelo do terminal, versão do Windows, aplicativo principal e periféricos disponíveis.
• Defina se o teste permite reinicialização, conexão de USB, mudança de configuração, uso de proxy e interação com sistemas de backend.
• Defina hosts e portas de rede que podem ser testados a partir do terminal.
• Combine previamente como evidências sensíveis devem ser mascaradas no relatório.
• Use contas de teste e dados sintéticos sempre que houver risco de acessar informações de clientes ou usuários reais.

Descubra qual mecanismo realmente está restringindo o Windows

O primeiro passo é entender se o dispositivo usa Assigned Access, Shell Launcher, uma experiência restrita com AppLocker, uma aplicação própria executada no logon ou uma combinação de políticas. A Microsoft deixa claro que Shell Launcher substitui o terminal padrão, mas não impede por si só o acesso a outros aplicativos e componentes do sistema.

Se uma sessão administrativa autorizada estiver disponível, comece com a configuração do Assigned Access:

Get-AssignedAccess

O comando mostra a conta associada e a aplicação configurada quando o modelo usa o módulo Assigned Access. Em ambientes gerenciados por MDM, CSP ou XML avançado, complemente a análise com a configuração entregue pela ferramenta de gestão e com as políticas efetivas no equipamento.

Colete também uma visão rápida do sistema e da identidade atual:

whoami
whoami /groups
whoami /priv
hostname
systeminfo | findstr /B /C:"OS Name" /C:"OS Version"

O resultado ajuda a registrar qual conta está executando o terminal, quais grupos ela herda e se existem privilégios inesperados. O ponto principal de um achado não é a existência de um privilégio isolado, mas se ele amplia o impacto de um eventual escape. 

Execute uma matriz controlada de tentativas de kiosk escape

A fase manual deve explorar todas as transições entre a aplicação principal e componentes do Windows. O pentester procura qualquer fluxo que entregue uma interface mais poderosa do que a originalmente permitida.

• Atalhos que tentam abrir Executar, Explorer, Configurações, Pesquisa, Gerenciador de Tarefas e recursos de acessibilidade.
• Menus de contexto e ações abertas por clique secundário, seleção de texto ou links externos.
• Caixas para abrir arquivo, salvar arquivo, exportar, importar, anexar e escolher diretório.
• Fluxos de impressão, pré-visualização e salvar como PDF.
• Links que acionam outro protocolo, aplicação externa ou nova janela do navegador.
• Mensagens de erro, telas de recuperação e comportamento após perda de rede.
• Fechamento inesperado do aplicativo principal e retorno do sistema depois da falha.
• Conexão de teclado, mouse, armazenamento removível e outros periféricos permitidos pelo escopo.

Em Assigned Access, vários atalhos conhecidos já são bloqueados pelo Windows. A validação permanece necessária porque o risco frequentemente aparece em fluxos fornecidos pela própria aplicação, como file pickers, impressão, URLs externas ou processos auxiliares.

Se o escape entregar um terminal, registre primeiro o contexto obtido

Depois de alcançar PowerShell, Prompt de Comando ou Explorer dentro do escopo autorizado, evite avançar imediatamente para ações invasivas. Primeiro, estabeleça a identidade, o nível de integridade e o alcance local. Isso cria uma prova reproduzível e reduz a necessidade de exploração adicional.

whoami
whoami /user
whoami /groups
whoami /priv
Get-LocalUser
Get-LocalGroupMember -Group Administrators

Um escape executado como usuário padrão e sem acesso a outros dados é diferente de um escape que entrega uma conta administrativa. Caso a identidade do kiosk pertença a Administrators ou herde direitos administrativos, o achado deve refletir que o impacto ultrapassa a simples quebra de interface.

Verifique a política efetiva de AppLocker

AppLocker é relevante porque um kiosk pode bloquear a interface visual e ainda permitir a execução de ferramentas locais. O pentester precisa verificar a política efetiva e testar caminhos específicos, em vez de assumir que a existência de uma GPO significa proteção suficiente.

Get-AppLockerPolicy -Effective
Get-AppLockerPolicy -Effective -Xml | Set-Content C:\Temp\applocker-effective.xml




Para testar se executáveis de um diretório seriam permitidos para o usuário avaliado, o próprio módulo AppLocker oferece Test AppLockerPolicy:




Get-AppLockerPolicy -Effective |
  Test-AppLockerPolicy -Path C:\Windows\System32\*.exe -User Everyone

Esse teste não substitui a validação real do usuário do kiosk, mas ajuda a identificar coleções sem regra, permissões amplas e binários que continuam permitidos. Se o AppLocker tiver sido aplicado via CSP, o cmdlet pode não refletir corretamente a política, portanto, a origem da configuração precisa ser confirmada.

Procure caminhos de execução fora da aplicação principal

Um kiosk é mais resistente quando a aplicação principal é apenas uma das poucas coisas que a conta consegue executar. Se ferramentas administrativas, interpretadores ou aplicações auxiliares continuam disponíveis, qualquer file picker ou protocolo externo pode ganhar importância.

Get-Process | Sort-Object ProcessName | Select-Object ProcessName, Id, Path
Get-CimInstance Win32_StartupCommand | Select-Object Name, Command, Location, User
Get-ScheduledTask | Where-Object State -ne Disabled | Select-Object TaskName, TaskPath, State

Use a saída para entender quais componentes fazem parte da experiência e quais processos podem ser acionados pelo usuário. Um processo auxiliar iniciado com privilégios maiores do que a conta do kiosk merece análise separada.

Revise arquivos locais, configurações e segredos com prova mínima

Aplicações de kiosk frequentemente armazenam URLs de API, connection strings, identificadores de cliente, certificados e tokens de sessão. Em um pentest autorizado, é razoável procurar indícios de exposição sem coletar mais dados do que o necessário.

Get-ChildItem C:\ProgramData, C:\Users -File -Recurse -ErrorAction SilentlyContinue |
  Where-Object { $_.Extension -in '.config','.xml','.json','.ini','.env' } |
  Select-String -Pattern 'password|secret|token|apikey|api_key|connectionstring' -CaseSensitive:$false

Se o comando retornar uma credencial real, interrompa a coleta quando a evidência já for suficiente. Registre caminho, tipo de dado, permissões do arquivo e impacto possível. Não copie bases completas, credenciais de usuários ou dados de clientes para demonstrar um problema que pode ser provado com uma amostra mascarada.

Também é útil revisar diretórios graváveis pela conta do kiosk:

$paths = 'C:\Program Files','C:\ProgramData','C:\Kiosk'
foreach ($p in $paths) {
  Get-ChildItem $p -Directory -ErrorAction SilentlyContinue |
    ForEach-Object {
      $acl = Get-Acl $_.FullName
      [PSCustomObject]@{Path=$_.FullName; Access=$acl.AccessToString}
    }
}

A análise deve procurar diretórios onde a conta do kiosk possa alterar conteúdo executado posteriormente por um processo mais privilegiado. A confirmação de exploração desse cenário só deve ocorrer se estiver explicitamente prevista no escopo.

Analise navegador e aplicação web como parte do kiosk

Quando o terminal usa Edge ou outro navegador, o navegador se torna uma ponte entre a interface restrita e o sistema. O pentester deve testar navegação, origem, downloads, uploads, nova janela, protocolos externos, armazenamento local e persistência de sessão.

• Tente navegar para URLs fora da allowlist usando links, redirecionamentos e campos de URL expostos pela aplicação.
• Verifique se downloads podem ser abertos por aplicações locais.
• Teste se as caixas de upload permitem navegar por diretórios não previstos.
• Valide se a sessão de um usuário é limpa antes do próximo atendimento.
• Observe se o navegador oferece impressão, salvar como PDF, ferramentas de desenvolvedor ou páginas internas em um fluxo acessível ao usuário.
• Verifique se erros de TLS, autenticação ou proxy entregam telas de sistema fora da experiência controlada.

Mapeie a conectividade do terminal sem transformar o teste em varredura indiscriminada

Depois de um escape, uma das perguntas mais importantes é se o terminal consegue alcançar ativos que não são necessários para sua função. Comece com a configuração local e conexões já existentes.

ipconfig /all
route print
arp -a
Get-NetTCPConnection | Sort-Object RemoteAddress | Select-Object State, LocalAddress, LocalPort, RemoteAddress, RemotePort, OwningProcess

Para validar um host específico autorizado no escopo, use um teste pontual:

Test-NetConnection 10.10.20.15 -Port 443
Test-NetConnection 10.10.20.20 -Port 445

Uma evidência forte não exige escanear toda a rede. Se um kiosk público alcança SMB, RDP, banco de dados, interfaces administrativas ou outros serviços internos sem necessidade de negócio, o problema já pode ser demonstrado com testes direcionados e autorizados.

Valide APIs assumindo que o terminal pode ser comprometido

O backend não deve confiar no terminal apenas porque a requisição veio de uma rede conhecida ou de um dispositivo gerenciado. Se a aplicação expõe endpoints, capture o fluxo por um proxy autorizado ou reproduza requisições apenas contra endpoints definidos no escopo.

curl.exe -I https://api.exemplo.local/health
curl.exe -s https://api.exemplo.local/version

O teste deve verificar autenticação, autorização por objeto e por função, validade de sessão, escopo dos tokens e possibilidade de reutilizar uma chamada fora do fluxo visual do kiosk. Ao encontrar um token, avalie seu escopo e tempo de vida sem utilizá-lo contra recursos fora do projeto.

Teste estados de falha, reinicialização e recuperação

Muitos escapes acontecem quando o sistema sai do fluxo padrão. Um terminal pode estar bloqueado no uso normal, mas expor o Explorer, o desktop, o prompt ou uma janela de erro após uma falha. 

1. Interrompa a conectividade de forma controlada, se permitido, e observe o comportamento da aplicação.
2. Feche a aplicação pelo mecanismo permitido pelo escopo e registre qual processo ou interface aparece em seguida.
3. Reinicie o terminal e verifique se o estado restrito é restaurado automaticamente.
4. Teste o comportamento depois de logout, timeout, atualização ou recuperação da aplicação.
5. Confirme se os arquivos temporários e as sessões do usuário anterior continuam acessíveis.

Como transformar resultados em achados úteis

Um bom achado de Kiosk Pentest mostra a cadeia completa. Em vez de reportar apenas que um atalho funcionou, explique o que o atalho permite, qual contexto de segurança foi obtido e até onde esse contexto alcança.

Exemplo de estrutura de evidência:

• Condição inicial: usuário não autenticado com acesso físico ao terminal.
• Ação: o fluxo da aplicação abre o seletor de arquivos e permite navegar até um executável permitido.
• Resultado: execução de PowerShell sob a identidade local do kiosk.
• Contexto: a conta pertence ao grupo Users, mas consegue ler o arquivo de configuração contendo credenciais de serviço.
• Impacto: a credencial permite autenticação em API interna e acesso a dados fora da função do terminal.
• Correção: remover o caminho de escape, restringir a execução, proteger a credencial e limitar a API e a rede ao mínimo necessário.

Checklist técnico de retest

• O fluxo original de kiosk escape deixou de abrir componentes externos.
• A conta do kiosk permanece sem privilégios administrativos desnecessários.
• A política efetiva de execução bloqueia ferramentas que não fazem parte do terminal.
• File pickers, impressão, downloads e protocolos externos estão restritos.
• Segredos identificados foram removidos, protegidos ou rotacionados.
• O dispositivo alcança somente destinos e portas exigidos pela aplicação.
• As APIs não confiam no dispositivo como única evidência de autorização.
• Falhas, reinicialização e recuperação retornam sempre a um estado restrito.
• Logs registram eventos relevantes para investigação e operação.

O objetivo é provar isolamento, não apenas configuração

A melhor forma de avaliar um kiosk é assumir que alguém terá tempo para interagir com ele. Assigned Access, Shell Launcher, AppLocker e políticas de navegador são controles importantes, mas o Pentest precisa validar como eles funcionam em conjunto com a aplicação, a conta local, os periféricos, os dados e a rede.

Quando um escape é encontrado, a análise não deve parar na abertura do desktop. O valor técnico consiste em medir o contexto obtido e demonstrar, com prova mínima e controlada, se o terminal permite acesso a dados, execução indevida ou alcance de outros ativos corporativos.

Como a Vantico avalia a segurança de kiosks e terminais

O Kiosk Pentest da Vantico avalia o terminal como um sistema completo. A análise combina testes manuais de kiosk escape com validação de sistema operacional, privilégios, periféricos, aplicação, APIs, dados locais e conectividade de rede, de acordo com o escopo autorizado.

O time valida o impacto dos caminhos encontrados e entrega evidências, classificação por severidade, recomendações e reteste após as correções. Conheça o Kiosk Pentest da Vantico e converse com o time sobre o cenário da sua operação.

Siga a Vantico nas redes sociais.

FAQ: Perguntas frequentes sobre Kiosk Escape

O que é kiosk escape?

É o contorno das restrições que deveriam manter o usuário dentro da aplicação ou experiência autorizada, permitindo acesso a componentes do sistema, arquivos, outras aplicações ou recursos não previstos.

Fullscreen é suficiente para proteger um kiosk?

Não. Tela cheia é uma característica de interface. Segurança depende de restrição do sistema, menor privilégio, controle de execução, tratamento de periféricos, proteção de dados e segmentação de rede.

Um pentest de kiosk precisa explorar privilégio local?

Somente quando isso estiver no escopo e for necessário para demonstrar impacto. Em muitos casos, provar um escape com contexto de usuário e acesso a um recurso indevido já é suficiente.

AppLocker elimina kiosk escape?

Não. AppLocker reduz caminhos de execução, mas o ambiente ainda precisa ser testado para interfaces secundárias, componentes permitidos, políticas aplicadas por CSP, navegador, arquivos, APIs e rede.