How Fake Cisco AnyConnect Installers Use JavaScript to Drop SharkLoader

Introduction: why fake installers still work

The report describes attackers getting traction from an old trick: name the file after something trusted, make it look like a normal installer, and let the victim start the chain.

Here the lure is a fake Cisco AnyConnect or Google Update installer, and JavaScript appears in the delivery path before SharkLoader shows up. That combination matters because it buries the real behavior under software people expect to run: installers, update prompts, and short-lived scripts that only exist to stage something worse.

My read: this is not a novel campaign. It is a standard social-engineering chain with a quieter middle step. The interesting part is not that JavaScript is involved. It is that JavaScript gives the attacker a small, adaptable launcher between the lure and the payload.

What the report says about the SharkLoader chain

The source material is thin, but the chain it describes is clear enough to analyze.

The lure: Cisco AnyConnect and Google Update branding

The report says the installers are branded as Cisco AnyConnect and Google Update. That is a sensible choice for the attacker because both names map to software people expect to install or update without much hesitation.

In practice, that works for three reasons:

• users are trained to click through setup flows quickly
• endpoint controls often tolerate installer behavior more than ordinary scripts
• security reviews sometimes give branded software a quick pass if the filename looks believable

That is why fake installer campaigns keep showing up. The attacker is not trying to beat careful validation. They are betting that the victim, or the control plane, will treat the file as routine maintenance.

The delivery step: JavaScript as a quiet launcher

The report says JavaScript is used in the delivery chain. It does not matter much to the attacker whether that is a .js file, embedded script, or something launched through Windows scripting host. The point is the same: use script execution as a staging layer.

That layer is useful because it can:

• unpack or fetch the next stage
• launch the payload under a familiar Windows process name
• add a delay or condition check before the real malware appears
• split suspicious logic across multiple files so no single artifact looks too loud

In other words, the script is not the payload. It is the bridge.

The payload step: where SharkLoader enters the flow

According to the report, the payload is SharkLoader. That is the stage defenders should care about most, but not because the name is exotic. Loader families matter because they create options: persistence, follow-on downloads, and remote control can all arrive later.

The key point is the transition. If you only hunt for a suspicious executable with a famous malware name, you can miss the earlier script stage that made the chain work. In a lot of real incidents, the loader is not launched by an obvious “malware” action. It is launched by a script that looks like installer glue.

What I confirmed versus what I did not

What the source material confirms:

• fake Cisco AnyConnect and Google Update installers are part of the lure
• JavaScript is used in the delivery chain
• SharkLoader is the payload named in the report

What I did not verify from the source:

• the exact file extension or script host used
• the hashes, URLs, or filenames of the sample
• whether the script was embedded, dropped, or downloaded
• the persistence and command-and-control details of SharkLoader in this campaign

That separation matters. Without the sample or a vendor advisory, it is better to stay precise than to invent mechanics.

Why JavaScript helps attackers in this kind of campaign

Scripted staging avoids obvious binary signatures

A compiled binary can be noisy in ways a script is not. A script can be short, obfuscated, and disposable. It can also split behavior across multiple steps so that no single file looks especially alarming.

That does not make scripts safer. It makes them more flexible.

For defenders, the practical consequence is that the malicious behavior may not begin where you first look. The first suspicious artifact may be:

• wscript.exe or cscript.exe starting from a user-writable path
• a script engine spawned by an installer-like file in Downloads
• a script that immediately launches another process or writes another file
• a burst of network activity after a brand-themed install prompt

Why this can slip past user scrutiny and some controls

A fake installer does not need to look perfect. It only needs to be believable enough to get one execution.

JavaScript helps because the user usually sees the wrapper, not the internal chain. If the file name says Cisco or Google, people assume the rest is normal. If the first stage is a script, some controls may still allow it if it is launched through a user action or bundled inside a staged install flow.

The risk is not just phishing. It is the gap between what the user thinks they ran and what the operating system actually executed.

What defenders should verify first

Check download sources, installer names, and execution paths

Start with the boring evidence. That is usually where the mistake is.

Look for:

• installers downloaded from non-vendor domains
• filenames that imitate Cisco AnyConnect or Google Update but do not match the vendor’s normal distribution pattern
• files launched from Downloads, Desktop, temp folders, or archive extract paths
• mismatches between file name, file signature, and expected install behavior

If you are triaging a host, the first question is simple: did the user run software from the vendor, or did they run a file that only looked like vendor software?

A quick Windows triage check for recent downloads and hashes:

Get-ChildItem "$env:USERPROFILE\Downloads" -Recurse -File |
  Select-Object FullName, Length, LastWriteTime |
  Sort-Object LastWriteTime -Descending |
  Select-Object -First 20

If one of those files is supposed to be an installer, verify the publisher, hash, and origin before doing anything else.

Inspect script execution, child processes, and network beacons

Once you suspect a script stage, follow the process tree.

You want to know:

• what launched the script engine
• what the script engine launched next
• whether the child process wrote files, touched startup locations, or opened outbound connections
• whether the first beacon went to a domain unrelated to Cisco or Google

On Windows with Sysmon, this kind of hunt is usually enough to start:

Get-WinEvent -FilterHashtable @{
  LogName = 'Microsoft-Windows-Sysmon/Operational'
  Id      = 1
} | Where-Object {
  $_.Message -match 'Image:.*\\(wscript|cscript|mshta)\.exe' -and
  $_.Message -match 'ParentImage:.*\\(Downloads|Temp|AppData)'
} | Select-Object -First 20 | Format-List TimeCreated, Message

What you want to see in a real hit is a script host started from a user-writable path, followed by a child process that does not fit the expected installer flow.

Concrete detection and response ideas for endpoint and SOC teams

Telemetry to hunt for fake installer behavior

If I were writing detections for this campaign class, I would start with these signals:

If your EDR supports process lineage, alert on the combination of a branded installer name plus a script host plus outbound network activity. That pattern is much stronger than any single filename.

Safe containment and cleanup steps after execution

If you find this on a host, do not keep experimenting on the original machine.

Use this sequence instead:

1. isolate the endpoint from the network
2. preserve process, file, and network telemetry
3. collect hashes and timestamps for the installer and any dropped scripts
4. inspect scheduled tasks, Run keys, startup folders, and recent services
5. remove the malicious files only after collection
6. reset credentials if the user entered any secrets after execution
7. reimage if you cannot prove the host remained clean

If the fake installer was launched on a workstation with VPN, browser, or cloud credentials, assume the risk extends beyond the endpoint until you verify otherwise.

What I confirmed and what remains unverified

What I confirmed

From the provided report summary, the campaign uses:

• fake Cisco AnyConnect installers
• fake Google Update installers
• JavaScript in the delivery path
• SharkLoader as the payload name

That is enough to draw a defender-focused conclusion: the attack relies on social trust plus a script-based staging layer.

What remains unverified

I did not confirm:

• the exact malware sample
• the hosting infrastructure
• the script contents
• the persistence mechanism
• the command-and-control details
• whether the campaign used signed binaries, HTML application files, or another launcher format

Those details would matter for a deeper reverse-engineering post, but they are not present in the source material I was given.

Bottom line: the real risk is trust in the installer, not the brand

My position is simple: this is a backend and endpoint trust problem dressed up as a branding problem.

Cisco AnyConnect and Google Update are just the costume. The actual failure is that the victim’s machine accepted a file from the wrong source and then executed a script that should have been treated as suspicious by default.

If you want to reduce exposure to campaigns like this, focus on three checks:

• provenance: where did the installer come from?
• lineage: what process launched the script and what did it spawn?
• behavior: did the “installer” act like legitimate software or like a dropper?

That is the real defense. Not memorizing brand names.