Skip to content
KitploitKITPLOIT
FerramentasBlog
Enviar
FerramentasBlog
Enviar

Ferramentas de Hacking, PenTest e Cibersegurança para o seu Arsenal de Segurança!

Kitploit é um diretório de ferramentas de hacking, cibersegurança e pentesting. Descubra as últimas atualizações de projetos para encontrar vulnerabilidades, analisar sistemas, automatizar testes e fortalecer sua segurança.

··Feeds·Contato·Privacidade·© 2026 Kitploit

Diretório de Ferramentas

Categorias

Ver todas as categorias
Loading categories
mxc — Política orientada, isolamento e contenção em camadas | Kitploit
Ferramentas/GitHubGitHub/microsoft/mxc
Segurança de Infraestrutura em NuvemFerramentas DefensivasSegurança de ContêineresAnálise Dinâmica (Sandboxing)Auditoria de ConfiguraçãoVirtualização para Segurança
GitHubmicrosoft/mxc

mxc

Política orientada, isolamento e contenção em camadas

Ver Repositório
1.3k7012há 1 diaRevisado pelo Kitploit

Mais Populares

Ver todos →

Descubra as ferramentas mais usadas pela nossa comunidade.

Explore todas as ferramentas

Navegue pela nossa coleção de ferramentas

Ver todas as ferramentas →
Compartilhar

Microsoft eXecution Container (MXC)

MXC é um sistema de execução de código em sandbox para executar código não confiável (saída de modelos, plugins, ferramentas) no Windows, Linux e macOS. Ele fornece múltiplos backends de contenção — desde sandboxes de processos nativos do SO até VMs completas — por trás de um esquema de configuração JSON unificado e um SDK TypeScript.

[!WARNING] Este repositório contém uma prévia inicial do código publicado para permitir integração antecipada e feedback de desenvolvedores sobre os Microsoft Execution Containers. Espera-se que as sandboxes subjacentes nesta prévia inicial mudem, pois estão em desenvolvimento contínuo; no entanto, buscaremos minimizar o impacto de compatibilidade à medida que a funcionalidade evolui. Há casos conhecidos em que as políticas atuais geradas pelo SDK MXC neste repositório são excessivamente permissivas e serão corrigidos antes que isso seja disponibilizado de forma mais geral. A parceria com pesquisadores de segurança enquanto o MXC amadurece é bem-vinda; no entanto, nenhum perfil MXC deve ser tratado atualmente como limite de segurança.

Recursos

  • Multiplataforma: Suporte para Windows, Linux e macOS com backends de contenção apropriados para cada plataforma
  • Configuração baseada em JSON: Defina parâmetros de execução e políticas de segurança por meio de um esquema JSON versionado
  • Múltiplos Backends de Contenção: ProcessContainer, Windows Sandbox, LXC, Bubblewrap, Seatbelt (macOS), MicroVM (NanVix), Hyperlight, IsolationSession e WSLC
  • Sandboxing Orientado por Políticas:
    • Política de Sistema de Arquivos: Listas de caminhos somente leitura e leitura/escrita (caminhos negados ainda não suportados no Windows)
    • Política de Rede: Suporte a proxy (cooperativo no Linux/macOS), permitir/bloquear saída e filtragem de host dependente do backend
    • Política de Interface: Controles de acesso à área de transferência, exibição e GUI
  • Ciclo de Vida Ciente de Estado: Ciclo de vida de sandbox em várias etapas (provisionar → iniciar → executar → parar → desprovisionar) para sandboxes de sessão
Baixar ferramenta
  • SDK TypeScript: Pacote npm @microsoft/mxc-sdk com APIs de execução única e cientes de estado
  • Diagnóstico: Registro de depuração e Event Tracing for Windows (ETW) para solução de problemas
  • Compilação

    O MXC inclui um wrapper de contêiner nativo além de um SDK TypeScript — consulte o README do SDK para documentação completa da API.

    Plataformas

    PlataformaBackend padrãoOutros backendsCompilação mínima
    Windows 11 24H2+ (verificado na 25H2)processcontainerwindows_sandbox, wslc, microvm, hyperlight, isolation_sessionprocesscontainer: 26100 (24H2)
    isolation_session: 26340.9212 (Insider Preview)
    Linux x64 / ARM64bubblewraplxc, microvm, hyperlight—
    macOS ARM64 / x64 (esquema 0.7.0-alpha+)seatbelt——

    Os backends estáveis de execução única (processcontainer, bubblewrap, lxc e seatbelt) não exigem modo experimental; hosts Linux também precisam do runtime correspondente instalado: bwrap (Bubblewrap) para o backend padrão, ou o conjunto de ferramentas lxc para o backend lxc. Backends experimentais (windows_sandbox, wslc, microvm, isolation_session, hyperlight) exigem { experimental: true } em SandboxSpawnOptions ou o sinalizador de CLI --experimental.

    Para saber quais aspectos de política de restrição de sistema de arquivos, rede e interface o backend processcontainer do Windows pode impor em cada versão do Windows 11 (23H2 / 24H2 / 25H2 / 25H2+), consulte Suporte de política por versão do SO Windows.

    Requisitos

    • Conjunto de ferramentas Rust — versão fixada em 1.93 via src/rust-toolchain.toml (selecionada automaticamente pelo rustup)
    • Node.js ≥ 18
    • npm (para compilações do SDK e da CLI)

    Estrutura do Projeto

    root@kitploit:~
    src/        Workspace Rust (binários nativos + crates de bibliotecas compartilhadas)
    sdk/        SDK TypeScript (pacote npm @microsoft/mxc-sdk)
    schemas/    Esquemas de configuração JSON (estáveis + dev)
    docs/       Documentação (referência de esquema, guias de backend, documentos de design)
    tests/      Material de teste (configurações, exemplos, scripts)
    scripts/    Scripts de compilação e utilitários
    

    Compilação Completa

    Windows

    root@kitploit:~
    build.bat                  # Compilação Release para a arquitetura atual
    build.bat --debug          # Compilação Debug
    build.bat --all            # Compilação Release para x64 e ARM64
    build.bat --with-microvm   # Incluir binários NanVix micro-VM
    

    Linux

    root@kitploit:~
    ./build.sh                 # Compilação Release
    ./build.sh --debug         # Compilação Debug
    ./build.sh --rust-only     # Apenas binários Rust, ignorar SDK/CLI
    

    macOS

    root@kitploit:~
    ./build-mac.sh             # Compilação Release para a arquitetura nativa
    ./build-mac.sh --all       # Apple Silicon e Intel
    ./build-mac.sh --debug     # Compilação Debug
    ./build-mac.sh --rust-only # Apenas binário Rust, ignorar SDK
    

    Todos os scripts de compilação:

    1. Compilam o binário Rust apropriado para a plataforma
    2. Copiam o binário para sdk/node/bin/<arch>/ (por exemplo, x64 ou arm64) para empacotamento do SDK
    3. Compilam o SDK TypeScript

    Compilação de Componentes Individualmente

    root@kitploit:~
    # Workspace Rust (a partir de src/)
    cargo build --release --target x86_64-pc-windows-msvc     # Windows x64
    cargo build --release --target aarch64-pc-windows-msvc    # Windows ARM64
    cargo build --release -p lxc                               # Linux — lxc-exec (atende LXC e Bubblewrap)
    cargo build --release -p mxc_darwin --target aarch64-apple-darwin  # macOS
    
    # SDK (a partir de sdk/node/)
    npm install && npm run build
    

    Lint e Formatação

    root@kitploit:~
    # Rust Windows (a partir de src/)
    
    cargo clippy --workspace --all-targets -- -D warnings
    
    # Rust Linux (a partir de src/; corresponde ao conjunto de crates compatível com a plataforma do build.sh)
    
    cargo clippy -p lxc -p lxc_common -p wxc_common -p bwrap_common -p unix_test_proxy --all-targets -- -D warnings
    
    # Rust macOS (a partir de src/)
    
    cargo clippy -p mxc_darwin -p seatbelt_common --all-targets -- -D warnings
    

    Testes

    root@kitploit:~
    # Testes unitários Rust (a partir de src/)
    cargo test --workspace
    cargo test -p wxc_common                      # Crate único
    cargo test -p wxc_common -- config_parser     # Filtrar por nome de teste
    
    # SDK (a partir de sdk/node/)
    npm test                     # Testes unitários
    npm run test:integration     # Testes de integração
    
    # E2E (a partir de src/)
    cargo test -p wxc_e2e_tests
    

    Uso

    O MXC usa uma configuração JSON para definir parâmetros de execução. Consulte a documentação do esquema para referência completa.

    Binário Nativo

    root@kitploit:~
    # Caminho do arquivo
    wxc-exec.exe config.json
    
    # Configuração codificada em Base64
    wxc-exec.exe --config-base64 <base64-encoded-json>
    
    # Saída de depuração
    wxc-exec.exe --debug config.json
    

    No Linux: ./lxc-exec config.json No macOS: ./mxc-exec-mac --experimental config.json

    SDK TypeScript

    root@kitploit:~
    npm install @microsoft/mxc-sdk
    
    root@kitploit:~
    import {
      spawnSandboxFromConfig, createConfigFromPolicy,
      getAvailableToolsPolicy, getTemporaryFilesPolicy,
      getPlatformSupport,
    } from '@microsoft/mxc-sdk';
    
    if (!getPlatformSupport().isSupported) {
      throw new Error('MXC not available on this host');
    }
    
    const tools = getAvailableToolsPolicy(process.env);
    const temp  = getTemporaryFilesPolicy();
    
    const config = createConfigFromPolicy({
      version: '0.6.0-alpha',
      filesystem: {
        readonlyPaths:  tools.readonlyPaths,
        readwritePaths: temp.readwritePaths,
      },
      network: { allowOutbound: false },
      timeoutMs: 30_000,
    });
    config.process!.commandLine = 'python -c "print(\'hello from sandbox\')"';
    
    const child = spawnSandboxFromConfig(config, { usePty: false });
    child.stdout!.on('data', (d) => process.stdout.write(d));
    child.on('close', (code) => console.log('exit:', code));
    

    O SDK também fornece uma API de ciclo de vida ciente de estado para sandboxes de longa duração:

    root@kitploit:~
    import {
      provisionSandbox, startSandbox, execInSandboxAsync,
      stopSandbox, deprovisionSandbox,
    } from '@microsoft/mxc-sdk';
    

    Consulte o README do SDK para documentação completa da API.

    Versões do Esquema

    Esquemas estáveis imutáveis lançados ficam em schemas/stable/; o esquema dev em andamento (backends experimentais, ciclo de vida ciente de estado) fica em schemas/dev/. As versões estável e dev atuais são rastreadas canonicamente em schemas/schema-version.json.

    Escolha o esquema estável mais recente para novo código em qualquer plataforma suportada. Consulte docs/versioning.md para o design completo de versionamento.

    Depuração

    Modo Console de Depuração

    Por padrão, os binários nativos executam em modo silencioso — stdin/stdout/stderr é acoplado diretamente ao contêiner. Use --debug para saída detalhada:

    root@kitploit:~
    wxc-exec.exe --debug config.json
    

    Consulte docs/diagnostics.md para referência completa de diagnóstico.

    Modo Auditoria (Modo de Aprendizado Permissivo)

    --audit é um wrapper de compatibilidade sobre processContainer.captureDenials em modo allow com retenção de ETL forçada. Ele injeta permissiveLearningMode, portanto operações negadas são registradas, mas têm permissão para prosseguir. Em hosts com o conjunto completo de APIs PSEC/V2 Learning Mode, o runner ProcessContainer selecionado usa captura nativa sem iniciar PLM ou solicitar elevação. Camadas mais antigas ou incompatíveis com políticas usam o fallback WPR protegido: wxc-exec.exe permanece sem elevação e inicia um guardião PLM elevado por UAC no escopo da sessão apenas para o ciclo de vida WPR privilegiado, comunicando-se por um pipe nomeado local autenticado. Ele é rejeitado para Windows Sandbox, WSLC, IsolationSession e todos os outros backends de contenção.

    root@kitploit:~
    wxc-exec.exe --audit policy.json
    

    Auditorias bem-sucedidas sem dry-run exigem metadados de captura, JSON de negações acionáveis e um ETL retido. A CLI realoca os caminhos selecionados pelo backend para denials.json e trace.etl no diretório de auditoria por usuário e, em seguida, gera um instantâneo da configuração de origem e Adjusted_*.json a partir do JSON acionável sem decodificar o ETL novamente. Entrada somente em Base64 mantém JSON e ETL, mas não tem configuração de origem para capturar ou ajustar. Análise truncada mantém JSON, ETL e o instantâneo de origem, mas ignora a geração de configuração ajustada. Use --audit-verbose para imprimir detalhes da política aprendida.

    Aviso: --audit injeta permissiveLearningMode — as restrições do AppContainer não são aplicadas durante a execução. Use apenas para criação de políticas. Não pode ser combinado com processContainer.captureDenials; use captureDenials.mode: "allow" para captura permissiva orientada por aplicativo. learningModeLogging e permissiveLearningMode são nomes de capacidades internas reservados e são rejeitados em processContainer.capabilities. Consulte docs/learning-mode/capabilities.md para os três fluxos de modo de aprendizado.

    Telemetria

    O MXC suporta telemetria ETW TraceLogging opcional para observabilidade de execução. Quando habilitada, eventos estruturados (MXC.Execution e MXC.Error) são emitidos para o subsistema ETW local por meio do crate Rust tracelogging. Cada evento inclui campos comuns (Version, Channel, IsDebugging, UTCReplace_AppSessionGuid) como dados de evento personalizado da Parte C.

    A telemetria exige:

    1. "telemetry": { "enabled": true } de nível superior na configuração JSON
    2. Consentimento explícito de telemetria por usuário no Windows
    3. Uma política administrativa que permita a coleta, quando uma política estiver configurada

    O sinalizador de configuração é um opt-in adicional por execução; ele não pode conceder consentimento ou contornar um bloqueio administrativo. A telemetria permanece desativada a menos que todos os portões aplicáveis estejam abertos. O MXC não usa a configuração Diagnóstico e comentários do Windows como substituto do consentimento do aplicativo.

    Em plataformas que não sejam Windows, todas as funções de telemetria são no-ops.

    Coleta de Dados

    O software pode coletar informações sobre você e seu uso do software e enviá-las à Microsoft. A Microsoft pode usar essas informações para fornecer serviços e melhorar nossos produtos e serviços. Você pode desativar a telemetria conforme descrito no repositório. Há também alguns recursos no software que podem permitir que você e a Microsoft coletem dados de usuários de seus aplicativos. Se você usar esses recursos, deverá cumprir a legislação aplicável, incluindo fornecer avisos apropriados aos usuários de seus aplicativos juntamente com uma cópia da declaração de privacidade da Microsoft. Nossa declaração de privacidade está localizada em https://go.microsoft.com/fwlink/?LinkID=824704. Você pode saber mais sobre coleta e uso de dados na documentação de ajuda e em nossa declaração de privacidade. Seu uso do software opera como seu consentimento para essas práticas.

    Como desativar a telemetria

    A telemetria está desativada por padrão. Para mantê-la desativada, não defina "telemetry": { "enabled": true } para a execução.

    Se a telemetria estiver habilitada na configuração, a coleta ainda não ocorre a menos que o consentimento do usuário do Windows seja concedido e a política administrativa permita a coleta.

    O que as compilações oficiais enviam

    As compilações oficiais/enviadas pela Microsoft definem um GUID de grupo de provedor TraceLogging no momento da compilação e roteiam eventos MXC.Execution e MXC.Error para a Microsoft por meio do pipeline UTC quando a telemetria está habilitada — essa mesma configuração em tempo de compilação também seleciona a palavra-chave Measures correta e a tag de privacidade Product-and-Service-Usage para os eventos, de modo que o roteamento de telemetria e a classificação de eventos sempre concordam. Compilações locais e de código aberto não enviam nada para a Microsoft por padrão — o código-fonte público é distribuído sem um GUID de grupo de provedor, portanto os eventos são emitidos apenas para o subsistema ETW local, usam uma palavra-chave local ao provedor sem significado UTC e não carregam tag de classificação de privacidade, e não são roteados para nenhum pipeline de coleta da Microsoft. Compilações internas que definem a variável de ambiente MXC_TELEMETRY_PROVIDER_GROUP_GUID no momento da compilação habilitam o caminho roteado pela Microsoft.

    Nenhum PII é coletado. Os eventos contêm apenas métricas de execução (duração, tipo de backend, código de saída) e uma categoria de erro limitada (error_type). Texto de mensagem de erro de forma livre nunca é emitido, portanto caminhos, nomes de usuário e credenciais não podem vazar pela telemetria. Se você usar o SDK para criar aplicativos, é sua responsabilidade fornecer avisos de telemetria apropriados aos seus próprios usuários.

    Informações de privacidade podem ser encontradas em https://privacy.microsoft.com e na declaração de privacidade da Microsoft em https://go.microsoft.com/fwlink/?LinkID=824704.

    Documentação

    DocumentoDescrição
    docs/schema.mdReferência completa do esquema de configuração JSON
    docs/versioning.mdVersionamento de esquema e ciclo de vida de recursos experimentais
    docs/examples.mdExemplos de configuração anotados
    docs/host-prep.mdPreparação do host Windows (wxc-host-prep.exe)
    docs/diagnostics.mdRegistro de diagnóstico e ETW
    docs/sandbox-policy/0.7.0/policy.mdEspecificação da política de sandbox 0.7.0
    docs/process-container/guide.mdGuia do Windows AppContainer / BaseContainer
    docs/lxc-support/lxc-backend.mdBackend LXC (Linux)
    docs/bwrap-support/bubblewrap-backend.mdBackend Bubblewrap (Linux)
    docs/seatbelt/seatbelt-backend.mdBackend Seatbelt (macOS)
    docs/windows-sandbox/windows-sandbox.mdBackend Windows Sandbox
    docs/state-aware-lifecycle/mxc-state-aware-sandbox-api.mdAPI de ciclo de vida de sandbox ciente de estado
    docs/telemetry/telemetry.md

    Contribuição

    Consulte CONTRIBUTING.md para diretrizes de contribuição.

    Licença

    Consulte LICENSE.md para detalhes.

    Arquitetura de telemetria TraceLogging
    docs/telemetry/telemetry-consent-design.mdContrato de consentimento de telemetria
    docs/telemetry/telemetry-administrative-policy.mdControles administrativos de telemetria