diff --git a/src/network-services-pentesting/pentesting-web/electron-desktop-apps/README.md b/src/network-services-pentesting/pentesting-web/electron-desktop-apps/README.md
index 05cdec3fcec..1b3db9f3ff2 100644
--- a/src/network-services-pentesting/pentesting-web/electron-desktop-apps/README.md
+++ b/src/network-services-pentesting/pentesting-web/electron-desktop-apps/README.md
@@ -467,6 +467,40 @@ Related reading on postMessage trust issues:
 ../../../pentesting-web/postmessage-vulnerabilities/README.md
 {{#endref}}
 
+## Post-exploitation: ASAR/main-process implants
+
+If you obtain **write access** to an Electron app resources directory, a very practical post-exploitation primitive is to **patch `app.asar`** (or the JS entrypoint it loads) and wait for the user to relaunch the app. Unlike a renderer-only XSS, code loaded from the **main process** executes in the app's **Node.js runtime**, so it can usually access the **filesystem**, spawn commands, hook Electron APIs, and inspect authenticated application state.
+
+Typical workflow:
+
+1. Extract `app.asar` and identify the real bootstrap file from `package.json` (`main`) or the existing startup logic.
+2. Add a small loader in the **main process** (or a preload/main-process hook) and repack the archive.
+3. Wait for the application to start again and use the implant to capture runtime data after the user unlocks or authenticates to the desktop app.
+
+Minimal bootstrap patch example:
+
+```javascript
+// Added near the application main entrypoint
+const cp = require("child_process")
+const { session } = require("electron")
+
+session.defaultSession.webRequest.onBeforeSendHeaders((details, callback) => {
+  // Inspect or copy authenticated headers/tokens here
+  callback({ requestHeaders: details.requestHeaders })
+})
+
+cp.exec("id")
+```
+
+Practical implications:
+
+- **Trusted-client data theft**: once the desktop app decrypts or loads data for the user, the implant can read it from the runtime. This is why **E2EE messaging clients** (Signal/Slack/Mattermost) and **vault/secret managers** are still interesting targets at the endpoint layer.
+- **Session/token abuse**: Electron implants can steal app cookies, bearer tokens, request headers, workspace files, or repo credentials exposed to the running client (for example, authenticated VS Code extensions or Git integrations).
+- **Victim-context pivoting**: a patched app can proxy requests through the victim workstation, reusing the victim IP, TLS fingerprint, and application session instead of only exfiltrating raw tokens.
+
+> [!NOTE]
+> If the target enables **ASAR integrity** / **OnlyLoadAppFromAsar** or hardened Electron **fuses**, you may need a different local code-loading primitive (for example, fuse abuse or snapshot tampering). See the macOS-specific injection page for more local implant options and fuse details.
+
 ## **Tools**
 
 - [**Electronegativity**](https://github.com/doyensec/electronegativity) is a tool to identify misconfigurations and security anti-patterns in Electron-based applications.
@@ -611,6 +645,7 @@ Detection and mitigations
 
 ## **References**
 
+- [JS-Tap v3: Endpoint Post-Exploitation With JavaScript Implants](https://trustedsec.com/blog/js-tap-v3-endpoint-post-exploitation-with-javascript-implants)
 - [Trail of Bits: Subverting code integrity checks to locally backdoor Signal, 1Password, Slack, and more](https://blog.trailofbits.com/2025/09/03/subverting-code-integrity-checks-to-locally-backdoor-signal-1password-slack-and-more/)
 - [Electron fuses](https://www.electronjs.org/docs/latest/tutorial/fuses)
 - [Electron ASAR integrity](https://www.electronjs.org/docs/latest/tutorial/asar-integrity)