Obfuscated_JavaScript

Scenario

Analyze the Obfuscated JavaScript as a Malware Analyst.

Executive Summary

The sample is a JScript file of roughly 2,200 lines, almost all of it junk comments. A small loader at the top reads the file back from disk and runs only the lines carrying a specific comment prefix through new Function, so the real payload never appears as ordinary code. Stripping that prefix statically exposed the hidden script. It checks whether a drive letter is already mapped, removes the mapping if so, maps a remote WebDAV-style share with net use, waits for the connection to settle, and installs an MSI from that share with msiexec. The sample was never executed; everything below comes from grep and cut.

Artifacts

• Danger.zip: password-protected archive holding the single JavaScript sample. The password is in danger.txt alongside it
• Sample script: one .js file, about 2,200 lines → read with grep and cut, never run

Gotcha: Two scripts exist in one file. The visible loader has its own ActiveX object and logic, and none of the questions are about it. Every answer lives in the hidden payload.

Defense Evasion

Extract the archive into a fresh directory first. Filtering out the comment lines leaves only the loader: it opens its own file with an ActiveX object and executes every line that starts with eight slashes. That prefix is the obfuscation, a line that looks like a comment to a skim-reader but is code to the loader. Strip the prefix from those lines to rebuild the hidden payload, then search it for ActiveXObject.

unzip -P "$(cat danger.txt)" Danger.zip -d x

grep -v '^\s*//' x/sample.js > code.js

grep '^////////' x/sample.js | cut -c9- > payload.js

grep -n 'ActiveXObject' payload.js

Gotcha: code.js also contains an ActiveXObject (Scripting.FileSystemObject, used to read the file back). It belongs to the loader, not the payload the question is about.

Discovery

WScript.Network from Q1 exposes the network object, and the payload calls its drive enumeration method inside a helper. Search for network. in payload.js to land on the call and the helper that wraps it.

grep -n 'network\.' payload.js

The enumeration call from Q4 sits inside a small function that loops the mapped drives and compares letters. That wrapper is the “is this drive mapped” check, and the main flow calls it before mapping and again before removing.

grep -n 'function' payload.js

Execution

Search the payload for winmgmts. The moniker string passed to GetObject ends in the namespace.

grep -n 'winmgmts' payload.js

The variable is declared once near the top of the payload as a plain var assignment, before the mapping logic that uses it.

grep -n 'attempt' payload.js

There is no Sleep call. After the net use command the script busy-waits on the system clock: it records a start time and spins in a while loop until the elapsed time passes a constant. That constant is the wait.

grep -n 'startTime' payload.js

Search for msiexec. The install command points /i at a UNC path on the remote share mapped by the net use step, and the filename at the end of that path is the package.

grep -n 'msiexec' payload.js

Tip: The share is addressed as \\host@80\share, the WebDAV over HTTP form of a UNC path. Note the host for the IOC list.

Follow the removal logic after the isDriveMapped check from Q8. The success branch and the failure branch each end in a WScript.Echo, and the else branch holds the failure message. The format hint’s trailing period is part of the string.

grep -n 'WScript.Echo' payload.js

Attack Summary

Phase	Action
Defense Evasion	Payload hidden in a file of junk comments; a small loader reads itself and runs only prefixed lines via new Function
Execution	Payload creates a WScript.Network object and a WMI connection to root\cimv2
Discovery	isDriveMapped wraps EnumNetworkDrives to check existing drive mappings
Execution	Removes an existing mapping if present, maps a remote share with net use, then waits 3 seconds in a clock loop
Execution	Installs avp.msi from the remote share with msiexec
Execution	Echoes a failure message if the drive removal does not succeed

IOCs

Type	Value
Domain	krd6[.]com
Share path	\\krd6[.]com@80\share
MSI package	avp.msi

MITRE ATT&CK

Technique	ID	Description
Obfuscated Files or Information	T1027	Payload hidden among junk comment lines and loaded at runtime
Command and Scripting Interpreter: JavaScript	T1059.007	JScript dropper run by the Windows script host
Windows Management Instrumentation	T1047	Script connects to the root\cimv2 WMI namespace
Network Share Discovery	T1135	EnumNetworkDrives checks which drive letters are mapped
System Binary Proxy Execution: Msiexec	T1218.007	msiexec /i installs the MSI from the remote share

Defender Takeaways

Comment-only content is not safe to ignore. A scanner that strips comments before analysis sees only a short loader here. Flag scripts that read their own file (Scripting.FileSystemObject opening WScript.ScriptFullName) and pass pieces of it to new Function or eval.

Block or alert on msiexec fetching from remote shares. An install path like \\host@80\share\file.msi is unusual on an endpoint. Alert on msiexec command lines containing a UNC path or @80, and restrict outbound WebDAV from workstations.

Watch net use from script hosts. wscript.exe or cscript.exe spawning net use or msiexec is a short, high-signal parent-child chain. Process creation logging with command lines catches it regardless of how the script was obfuscated.

Treat .js attachments as executables. Associating .js with Notepad instead of the Windows script host removes the double-click execution path for this class of dropper.

Conclusion

The sample hides a short share-mapping and MSI installer script inside a wall of comments, so the only reliable way to see it is to read the file as data. The static trick was trivial once spotted: strip the prefix and the payload reads in plain text.