T1574.002 DLL Side-Loading — Signed javac.exe Loading jli.dll from a User-Writable Path

The legitimate Oracle Java compiler launcher javac.exe loading jli.dll from a user-writable directory such as %TEMP% or %APPDATA%. javac.exe imports jli.dll (JLI_Launch) by name and resolves it by DLL search order from its own directory, so dropping a malicious jli.dll beside a copy of the signed javac.exe executes attacker code inside a trusted, signed host — classic search-order side-loading. Observed as the payload-execution stage of a ClickFix/EtherHiding loader: the loader dropped a signed javac.exe plus a 3.5 MB malicious jli.dll into a random %TEMP% subdirectory and ran the launcher, which side-loaded the DLL; the DLL was ACR Stealer. A legitimate JDK ships javac.exe and jli.dll together under Program Files, never out of a per-user temp path, so the combination of this specific image/module pair with a user-writable load path is the signal. Anchor on the path, not on file hashes: the javac.exe is a genuine signed binary and the jli.dll rotates.

Intel context

The technique this rule covers is quiet in the corpus this week — no current KEV, OSINT, or active-family signal. The detection stands ready; there is simply nothing exercising it right now. (Checked September 18, 2026.)

Rule ID: f6274ebe-cd01-5f2c-836f-f70dabfce048
Status: experimental
Level: high
Log source: category: image_load · product: windows
Date: 2026-08-14
Modified: 2026-08-14
ATT&CK: T1574.002 (signal rollup)
Canonical YAML: t1574-002-signed-javac-sideload-jli.yml

References

False positives

Portable or unpacked JDK distributions run from a user directory. Real but uncommon in managed environments; a genuine JDK keeps javac.exe and jli.dll together under a versioned jdk/bin path — allowlist that specific directory rather than the image/module pair.
Developer tooling that stages a JDK into a temp path during CI or first-run setup. Confirm the jli.dll is Oracle-signed before dismissing.

Rule YAML

title: 'T1574.002 DLL Side-Loading — Signed javac.exe Loading jli.dll from a User-Writable Path'
id: 'f6274ebe-cd01-5f2c-836f-f70dabfce048'
status: 'experimental'
description: 'The legitimate Oracle Java compiler launcher javac.exe loading jli.dll from a user-writable directory such as %TEMP% or %APPDATA%. javac.exe imports jli.dll (JLI_Launch) by name and resolves it by DLL search order from its own directory, so dropping a malicious jli.dll beside a copy of the signed javac.exe executes attacker code inside a trusted, signed host — classic search-order side-loading. Observed as the payload-execution stage of a ClickFix/EtherHiding loader: the loader dropped a signed javac.exe plus a 3.5 MB malicious jli.dll into a random %TEMP% subdirectory and ran the launcher, which side-loaded the DLL; the DLL was ACR Stealer. A legitimate JDK ships javac.exe and jli.dll together under Program Files, never out of a per-user temp path, so the combination of this specific image/module pair with a user-writable load path is the signal. Anchor on the path, not on file hashes: the javac.exe is a genuine signed binary and the jli.dll rotates.'
references:
    - 'https://thrunt.me/research/2026-08-11-etherhiding-onchain-conversion-registry/'
    - 'https://attack.mitre.org/techniques/T1574/002/'
author: 'Applied Cybernetics Group (via thrunt.me)'
date: '2026-08-14'
modified: '2026-08-14'
tags:
    - 'attack.defense_evasion'
    - 'attack.persistence'
    - 'attack.privilege_escalation'
    - 'attack.t1574.002'
    - 'tlp.clear'
logsource:
    category: 'image_load'
    product: 'windows'
detection:
    selection_pair:
        Image|endswith: '\javac.exe'
        ImageLoaded|endswith: '\jli.dll'
    selection_writable_path:
        ImageLoaded|contains:
            - '\AppData\Local\Temp\'
            - '\AppData\Roaming\'
            - '\Users\Public\'
            - '\Windows\Temp\'
            - '\ProgramData\'
    condition: 'selection_pair and selection_writable_path'
falsepositives:
    - 'Portable or unpacked JDK distributions run from a user directory. Real but uncommon in managed environments; a genuine JDK keeps javac.exe and jli.dll together under a versioned jdk/bin path — allowlist that specific directory rather than the image/module pair.'
    - 'Developer tooling that stages a JDK into a temp path during CI or first-run setup. Confirm the jli.dll is Oracle-signed before dismissing.'
level: 'high'

The YAML file above is the canonical artifact — machine consumers should subscribe via /sigma/manifest.json and fetch t1574-002-signed-javac-sideload-jli.yml directly. Each rule's live intel context is in /sigma/evidence.json keyed by slug. This page is a rendered view, regenerated daily.