Fast javascript security triage: hunting backdoors and vulnerabilities with grep

Auditing code under tight deadlines requires immediate visibility. Recently, I needed to perform rapid security triage across several JavaScript files to check for injected malicious payloads, hidden backdoors, and common vulnerabilities.

While dedicated Static Application Security Testing (SAST) engines exist, when you are troubleshooting directly from a server terminal, standard tools like grep remain the fastest first responder.

Below are the exact commands and regex filters I use for clean, effective triage.

The initial hurdle: quick scans vs. the node_modules black hole#

The immediate challenge when scanning JavaScript projects is preventing grep from choking on thousands of nested node_modules dependencies while searching for dangerous functions.

Here is the all-in-one baseline command for a quick initial sweep:

grep -rnEI --include='*.js' --exclude-dir=node_modules "(eval\(|setTimeout\([^,]+,|setInterval\([^,]+,|atob\(|btoa\(|innerHTML|document\.write\(|child_process|exec\(|spawn\(|Function\()" .

• Why it works: -r enables recursive directory scanning, -n outputs line numbers for quick jumping, and -E activates extended regex parsing. The --exclude-dir=node_modules flag keeps execution lightweight and prevents scanning third-party dependencies.

Targeted regex patterns by vulnerability class#

Broad searches often yield too much output. Breaking down the scan by target behavior keeps findings actionable:

1. Obfuscated code and backdoors#

Attackers routinely obfuscate malicious scripts to avoid basic inspection.

To identify dynamic code evaluation (the foundation of web shells and loaders):

grep -rnE "eval\(|Function\(|setTimeout\(['\"]|setInterval\(['\"]" file.js

To hunt for Base64-encoded strings:

grep -rnE "atob\(|btoa\(" file.js

To catch dense Hexadecimal or Unicode escape sequences:

grep -rnE "(\\x[0-9a-fA-F]{2}){4,}|(\\u[0-9a-fA-F]{4}){4,}" file.js

Practical tip: Malicious injections are often minified into a single massive line at the bottom of an otherwise normal script. Use awk to locate lines exceeding 500 characters:

awk 'length($0) > 500' file.js

2. DOM XSS vulnerabilities (frontend)#

When reviewing client-side code, focus on unescaped inputs reaching the browser DOM:

Direct HTML injections:

grep -rnE "\.innerHTML|\.outerHTML|document\.write\(|document\.writeln\(" file.js

Unvalidated open redirects (often abused in phishing campaigns):

grep -rnE "window\.location|location\.href|location\.replace" file.js

3. Command injection and file access (backend / Node.js)#

On the server side, unvalidated calls can lead to Remote Code Execution:

For Command Injection:

grep -rnE "require\(['\"]child_process['\"]\)|exec\(|execSync\(|spawn\(|spawnSync\(" file.js

For Path Traversal (unrestricted filesystem access):

grep -rnE "fs\.readFile\(|fs\.readFileSync\(|fs\.writeFile\(" file.js

Conclusion: from emergency grep triage to automated SAST#

grep is a rapid triage mechanism, but it does not parse abstract syntax trees (AST): it will flag commented code or legitimate polyfill patterns.

For quick incident response and ad-hoc code audits over SSH, these commands provide immediate clarity. For long-term code quality, the logical upgrade is wiring automated rules into Semgrep or configuring security plugins in ESLint within your CI pipelines.

See also

WordPress How to Detect and Clean Compromised WordPress Sites: Complete Forensic & Sanitization Guide

WordPress Post-Mortem: Control Panel Session Hijacking and WordPress Core Exploitation

Development Fixing Google OAuth 2.0 error 400: redirect_uri_mismatch troubleshooting guide

This post is licensed under CC BY-NC.