91 lines
2.9 KiB
Markdown
91 lines
2.9 KiB
Markdown
---
|
|
name: analyzing-java-jar-malware
|
|
description: 'Analyzes Java/JAR malware (such as Adwind/jRAT-class cross-platform RATs) by
|
|
inventorying the archive, reading the manifest entry point, detecting obfuscators and string
|
|
encryption, and flagging suspicious runtime, reflection, and networking class usage. Activates
|
|
for requests to analyze a malicious JAR, inspect Java malware, or identify a Java RAT.'
|
|
domain: cybersecurity
|
|
subdomain: reverse-engineering
|
|
tags:
|
|
- reverse-engineering
|
|
- java
|
|
- jar
|
|
- rat
|
|
- decompilation
|
|
version: 1.0.0
|
|
author: analyst-ai-pack
|
|
license: Apache-2.0
|
|
mitre_attack:
|
|
- T1059
|
|
- T1027
|
|
- T1620
|
|
d3fend:
|
|
- D3-SDA
|
|
- D3-DA
|
|
references:
|
|
- 'JAR/ZIP and Java class file format — https://docs.oracle.com/javase/specs/jvms/se17/html/'
|
|
- 'MITRE ATT&CK T1027 Obfuscated Files or Information — https://attack.mitre.org/techniques/T1027/'
|
|
---
|
|
|
|
# Analyzing Java/JAR Malware
|
|
|
|
## When to Use
|
|
|
|
- You have a malicious or suspicious `.jar` (often a cross-platform RAT) and need to map its
|
|
structure, entry point, obfuscation, and capability surface before decompiling.
|
|
- You want to triage a Java payload without running the JVM.
|
|
|
|
**Do not use** `java -jar` to run it — that executes the malware. Treat the JAR as a ZIP and read
|
|
its contents statically.
|
|
|
|
## Prerequisites
|
|
|
|
- The JAR file, read inertly. Optional: a Java decompiler (CFR, Procyon) for the next stage.
|
|
|
|
## Safety & Handling
|
|
|
|
- Read the archive statically; never launch the JVM on the sample. Defang any URLs found.
|
|
|
|
## Workflow
|
|
|
|
### Step 1: Inventory the archive and entry point
|
|
|
|
```bash
|
|
python scripts/analyst.py inspect sample.jar
|
|
```
|
|
|
|
Lists `.class` files, embedded resources/payloads (nested JARs, scripts, encrypted blobs), and
|
|
reads `META-INF/MANIFEST.MF` for `Main-Class`/`Premain-Class`.
|
|
|
|
### Step 2: Detect obfuscation and packers
|
|
|
|
Flags obfuscator fingerprints (Allatori, ProGuard, Zelix), single-character class/package names,
|
|
and string-decryption indicators.
|
|
|
|
### Step 3: Flag capability classes
|
|
|
|
Surface dangerous API usage in strings/constant pools: `Runtime.exec`/`ProcessBuilder`,
|
|
`java.lang.reflect`, `URLClassLoader`, `javax.crypto`, `java.net.Socket`, registry/persistence
|
|
helpers.
|
|
|
|
### Step 4: Route to decompilation
|
|
|
|
Hand the key classes to a decompiler (CFR/Procyon) for source recovery; record IOCs.
|
|
|
|
## Validation
|
|
|
|
- The manifest entry point is read and reported.
|
|
- Embedded payloads/nested archives are enumerated.
|
|
- Capability flags are backed by concrete class/string evidence.
|
|
|
|
## Pitfalls
|
|
|
|
- String-encrypted samples where capability strings appear only after decryption.
|
|
- Multi-stage droppers that unpack a second JAR at runtime.
|
|
- Benign obfuscated commercial JARs — corroborate with capability and delivery context.
|
|
|
|
## References
|
|
|
|
- See [`references/api-reference.md`](references/api-reference.md) for the inspector.
|
|
- JVM/JAR format and ATT&CK T1027 references (linked in frontmatter).
|