You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
## Node.js / Electron module resolution hijacking via `C:\node_modules`
891
+
892
+
This is a **Windows uncontrolled search path** variant that affects **Node.js** and **Electron** applications when they perform a bare import such as `require("foo")` and the expected module is **missing**.
893
+
894
+
Node resolves packages by walking up the directory tree and checking `node_modules` folders on each parent. On Windows, that walk can reach the drive root, so an application launched from `C:\Users\Administrator\project\app.js` may end up probing:
If a **low-privileged user** can create `C:\node_modules`, they can plant a malicious `foo.js` (or package folder) and waitfora **higher-privileged Node/Electron process** to resolve the missing dependency. The payload executesin the security context of the victim process, so this becomes **LPE** whenever the target runs as an administrator, from an elevated scheduled task/service wrapper, or from an auto-started privileged desktop app.
902
+
903
+
This is especially common when:
904
+
905
+
- a dependency is declared in`optionalDependencies`
906
+
- a third-party library wraps `require("foo")`in`try/catch` and continues on failure
907
+
- a package was removed from production builds, omitted during packaging, or failed to install
908
+
- the vulnerable `require()` lives deep inside the dependency tree instead of in the main application code
909
+
910
+
### Hunting vulnerable targets
911
+
912
+
Use **Procmon** to prove the resolution path:
913
+
914
+
- Filter by `Process Name` = target executable (`node.exe`, the Electron app EXE, or the wrapper process)
915
+
- Filter by `Path``contains``node_modules`
916
+
- Focus on `NAME NOT FOUND` and the final successful open under `C:\node_modules`
917
+
918
+
Useful code-review patterns in unpacked `.asar` files or application sources:
1. Identify the **missing package name** from Procmon or source review.
930
+
2. Create the root lookup directory if it does not already exist:
931
+
932
+
```powershell
933
+
mkdir C:\node_modules
934
+
```
935
+
936
+
3. Drop a module with the exact expected name:
937
+
938
+
```javascript
939
+
// C:\node_modules\foo.js
940
+
require("child_process").exec("calc.exe")
941
+
module.exports = {}
942
+
```
943
+
944
+
4. Trigger the victim application. If the application attempts `require("foo")` and the legitimate module is absent, Node may load `C:\node_modules\foo.js`.
945
+
946
+
Real-world examples of missing optional modules that fit this pattern include `bluebird` and `utf-8-validate`, but the **technique** is the reusable part: find any **missing bare import** that a privileged Windows Node/Electron process will resolve.
947
+
948
+
### Detection and hardening ideas
949
+
950
+
- Alert when a user creates `C:\node_modules` or writes new `.js` files/packages there.
951
+
- Hunt for high-integrity processes reading from `C:\node_modules\*`.
952
+
- Package all runtime dependencies in production and audit `optionalDependencies` usage.
- Disable optional probes when the library supports it (for example, some `ws` deployments can avoid the legacy `utf-8-validate` probe with `WS_NO_UTF_8_VALIDATE=1`).
955
+
890
956
## Network
891
957
892
958
### Shares
@@ -2022,5 +2088,9 @@ C:\Windows\microsoft.net\framework\v4.0.30319\MSBuild.exe -version #Compile the
2022
2088
- [A Link to the Past. Abusing Symbolic Links on Windows](https://infocon.org/cons/SyScan/SyScan%202015%20Singapore/SyScan%202015%20Singapore%20presentations/SyScan15%20James%20Forshaw%20-%20A%20Link%20to%20the%20Past.pdf)
0 commit comments