back

Inside Adwind: Deobfuscation and Payload Analysis

This post details the deobfuscation and behavioral analysis of an Adwind RAT sample. The sample can be found on VirusTotal:
https://www.virustotal.com/gui/file/00de57cf3c4496256c82f79b8c97136b434b9037408d94a3f0dc07123914fcf6

Initial Observations: JAR Decompilation

Decompiling the JAR file with JD-GUI revealed several classes, but most failed to load properly or returned empty results:

Switching to an alternative JAR decompiler yielded better results, revealing actual executable logic and embedded resources:

This behavior may be a basic anti-decompilation measure used to hinder static analysis.

Runtime String Deobfuscation

Analysis of the code showed that strings are obfuscated and decoded at runtime using two functions: ??j.??c and ??o.??c.

For example, ??j.??c is implemented as follows:

To automate string decryption, I extracted the deobfuscation logic into a custom JAR, allowing dynamic inspection of values using a debugger.

Once the strings were deobfuscated, I was able to follow the execution flow more clearly.

Embedded resources

Several decrypted strings pointed to embedded resources: /burn.om, /snake.green, and /dragon.fire. These were extracted and used as explained below:

• /dragon.fire - used as RSA Private key to decrypt /snake.green
• /snake.green - is an encrypted AES key
• /burn.om - Encrypted data that would be decrypted by the AES key

(var2 = (new Cipher.getInstance).??L("RSA")).init(2, (RSAPrivateKey)"/dragon.fire");
      Object var3 = (new Cipher.getInstance).??L("AES");
      byte[] var6 = var2.doFinal("/snake.green");
      SecretKeySpec var7 = new SecretKeySpec(var6, "AES");
      boolean var10005 = true;
      var3.init(2, var7);
      Object var4 = var3.doFinal("/burn.om"); 

The decrypted is then used to initialize a new object var1000 with the follow strings passed in as arguments to the object’s methods.

• PRIVATE_PASSWORD
• PASSWORD_CRYPTED
• SERVER_PATH

The method loadFromXML is called on the decrypted result.

public __j/* $FF was: ??j*/(InputStream var1) throws IOException {
      super.loadFromXML(var1);
   }

With a debugger, the XML object contains the following key and value pairs.

The values of the keys are extracted and stored into var8,var9 and var11.

Additional Embedded JARs and Payload Unpacking

Further inspection revealed additional resources located in paths such as Y/tna and Zd/EdG:

Following similar patterns as before, pc.PJx and n.gDa were used to derive another encrypted payload, jEX.K, which is dynamically loaded at runtime. This payload is likely a second-stage component.

Using the same approach, I included them in my JAR program.

And dump out var10 into a file.

Decompiling this second-stage JAR revealed another layer of obfuscation:

OS-specific execution paths are present. For example, Windows-specific logic invokes wscript:

And includes Windows Registry interactions:

Deobfuscating Final Stage Strings and Configuration

While researching the obfuscation technique, I found a JPCERT/CC blog post describing a similar approach used by Adwind.

It is also explained that Adwind is typically packed and that its main jar is hidden in the artefacts jar file, which appears to be the same for this sample.

Using their tool aa-tools, I successfully decrypted the final payload strings:

The structure confirms the malware’s modular nature and use of runtime unpacking, consistent with previously reported Adwind samples.

I also came across a written blog: https://www.malwarebytes.com/blog/news/2017/01/from-a-fake-wallet-to-a-java-rat

In the writeup for stage3, the obfuscation technique appears to be the same and similar folder structure with the same interesting files: Key1.json, Key2.json and config.json

The decryption is the same as the previous layer: where Key1.json is the RSA private key, Key2.json is the AES encrypted key and config.json is the AES encrypted config file.

{
  "NETWORK": [
    {
      "PORT": 1975,
      "DNS": "212.7.208.143"
    }
  ],
  "INSTALL": true,
  "MODULE_PATH": "N/waz/XqH.F",
  "PLUGIN_FOLDER": "OWIkDIPiAnT",
  "JRE_FOLDER": "EripyZ",
  "JAR_FOLDER": "NhXrPhGLjBP",
  "JAR_EXTENSION": "nTBxde",
  "ENCRYPT_KEY": "eAbPJnPvPODNPmUmFrFvtfYbe",
  "DELAY_INSTALL": 10,
  "NICKNAME": "User",
  "VMWARE": false,
  "PLUGIN_EXTENSION": "qAaHa",
  "WEBSITE_PROJECT": "https://jrat.io",
  "JAR_NAME": "XQwzYcLSbpH",
  "SECURITY": [
    {
      "PROCESS": [
        "MSASCui.exe",
        "MsMpEng.exe",
        "MpUXSrv.exe",
        "MpCmdRun.exe",
        "NisSrv.exe",
        "ConfigSecurityPolicy.exe"
      ],
      "NAME": "Windows Defender"
    }
  ],
  "JAR_REGISTRY": "FmQDzPEQFkf",
  "DELAY_CONNECT": 2,
  "SECURITY_TIMES": 20,
  "VBOX": false
}

Conclusion & Next Steps

This analysis highlights Adwind’s multi-layered obfuscation and use of embedded resources to evade detection and delay analysis.

Next steps may include:

• Performing full behavioral analysis of the second-stage payload using sandboxing or dynamic tracing.
• Investigating persistence and communication mechanisms.

Adwind demonstrates a high level of obfuscation and modularity, making it a persistent threat that requires layered analysis techniques.