A.

1: Software Exploitation (Direct Code Injection)

Planning
The objective entails leveraging explo7.c to strategically flood the call stack buffer, manipulate
the return address without causing a crash, and divert execution flow to injected code within the
heap. In essence, the attacker capitalizes on vulnerabilities within the printf function, enabling
the insertion of custom character strings onto the stack, consequently leading to a buffer
overflow scenario. Specifically, the explo7_x executable serves as the focal point for
exploitation.
To elaborate, the process involves embedding executable code into the target program, often
referred to as a "process" during execution. Our primary aim is to integrate simplistic code
segments into the application's library calls while specifying desired arguments. Notably, the
program operates as an echo server, actively monitoring incoming TCP connections from clients
across a designated port. Data transmission occurs in a continuous stream from the client to the
server, forming the operational context for exploitation and intrusion attempts.
Key points to consider:
 Utilization of explo7.c to manipulate call stack buffer and return addresses effectively.
 Exploitation revolves around vulnerabilities within the printf function, facilitating buffer
overflow.
 Target executable, explo7_x, serves as the primary focus for intrusion.
 Integration of executable code into the target program, termed as a "process" during
execution.
 Objective entails embedding simplistic code segments into application's library calls with
specified arguments.
 Operational context involves the program functioning as an echo server, monitoring TCP
connections on a designated port.
 Data transmission occurs in a continuous stream from clients to the server, forming the
basis for exploitation strategies.

A Python script named tcp_client1.py is used to implement our client.

Finding Buffer Overflow via Fuzzing

Upon analysis of the provided information, it becomes evident that a segmentation error occurs
within our target program when it receives an input byte stream totaling 70 bytes in length. This
error manifests due to the substitution of the original Return Address with the hexadecimal value
0x44444444, which corresponds to 'DDDDDD' in ASCII representation.
Key Points:
 Segmentation error occurrence attributed to the target program's reception of a 70-byte
input byte stream.
 The original Return Address is replaced by the hexadecimal value 0x44444444
('DDDDDD' in ASCII).
In essence, the segmentation error signifies a critical deviation from the expected program
behavior, indicating a breach or instability within the program's execution flow. The substitution
of the Return Address with a specific hexadecimal value suggests a deliberate attempt to
manipulate the program's control flow, possibly as part of an exploitation or intrusion strategy.
Analysis of Stack
Following the initial segmentation error encounter, our next course of action involves identifying
the precise location in memory where the stream of byte values is positioned within the stack of
our target program. This step is crucial for determining the offset required to pinpoint the Return
location accurately.
Upon conducting additional investigation, it was discerned that the connection_loop function
within our target application is responsible for allocating the buffer that contains the byte stream.
This function serves as the pivotal point where the byte stream is placed onto the stack.
To facilitate the determination of the offset, it is imperative to set a breakpoint immediately
before the connection_loop function concludes its execution. This strategic breakpoint placement
allows us to introspect the memory state and ascertain the offset value necessary for subsequent
actions.
Key Points:
 Objective: Identify memory location housing the byte stream within the target program's
stack.
 Importance of determining offset for precise Return location identification.
 Identification of connection_loop function as responsible for managing buffer allocation.
 Buffer containing byte stream positioned within the stack during execution of
connection_loop function.
 Strategic placement of breakpoint before function conclusion to capture memory state
and derive offset value.
By meticulously examining the program's execution flow and memory organization, we aim to
gain deeper insights into its underlying mechanisms. This investigative approach enables us to
acquire crucial information essential for devising effective strategies aimed at addressing
program vulnerabilities and enhancing overall system security.

Restarting the compilation and waiting for the program to go to main.

Upon close inspection, we've noticed that the stack starts storing the byte stream at memory
address 0xf7ff963c. Also, the old education and training data are kept at memory address
0xf7ff9678, as indicated by the base pointer (ebp). Right next to this, we find the Return Address
at 0xf7ff967c.
By looking at these addresses, we can tell that there's a 64-byte gap between the start of the byte
stream and the Return Address.
Key Points:
 The byte stream begins at 0xf7ff963c in memory.
 The previous education and training data are stored at 0xf7ff9678, confirmed by the base
pointer (ebp).
 The Return Address is found at 0xf7ff967c.
 The offset, indicating the gap between the start of the byte stream and the Return Address,
is 64 bytes.
Creating Shellcode from C Code
It is our intention to create printf() machine code. Make a basic application using our code:

Run the compiler with the option to "-S msg_machine_code" to view the code_in function's
source code in the object file.

Load Effective Address (Lea): This operation helps in loading an effective address.
Push: This operation decrements the Stack Pointer by 4 bytes and adds a 32-bit integer to the
stack. This integer points to the location of the string intended for printing.
Contact (Add): After the puts call, this function adjusts the Stack Pointer by adding 0x10 (16 in
decimal) to it.
Addition (Add): This operation restores the Stack Pointer, accounting for the 12 bytes from the
sub operation and 4 bytes from the push operation. In total, it deals with 16 bytes of adjustment.
No Operation (Nop), Depart, and Return (Ret): Following the 16 bytes of machine code
generated by printf(), three bytes each are reserved for these instructions.
In total, we're inserting 19 bytes of code. The addresses stored within the code also need careful
consideration for proper execution. We'll delve into that shortly.
\x83\xec\x0c\x68\xss\xss\xss\xss\xe8\xrr\xrr\xrr\xrr\x83\xc4\x10\x90\xc9\xc3
Planning the Overflow
We have ten No Operation (NOP) instructions, which essentially mean the processor does
nothing for a short period.
There are nineteen code instructions, likely related to program functions.
Eight spaces indicate certain gaps or separators within the data.
Additionally, we have sixteen more spaces for other purposes.
Four base pointers are stored, indicating memory addresses used for referencing data.
Four return addresses are also noted, possibly for controlling program flow.
Furthermore, there are four original old EBP (Extended Base Pointer) values stored, which help
with function calls.
Finally, we have four original return addresses, indicating where the program should return after
executing certain functions.
The sequence of characters like '\x90' represents hexadecimal values. For example, '\x90' is a
NOP instruction. The '\xss' and '\xrr' represent placeholders for specific memory addresses or
values.

Lastly, we see some strings like 'Hellooo AAAAAAAAAAAAAAAA', which could be part of
the program's output or input data. The other hexadecimal sequences likely represent memory
addresses or encoded data within the program.
Determine Addresses
Let's analyze the call stack of the target process.
The character buffer overflow begins at memory address 0xf7ff963c.
Sixty bytes later, at memory address 0xf7ff9678, we find the saved base address.
Continuing on the stack, at memory address 0xf7ff967c, we encounter the return address. This
address will be used to fill in the address of the code injection.
At memory address 0xf7ff968c, we have the parameter called ReturnAddressToCode:
\x43\x96\xff\xf7.
Following that, at memory address 0xf7ff9680, the value of OriginalOldEBPStored is saved.
This value helps us return to the original starting point.
The original return address is stored at memory address 0xf7ff9684, noted as 0x0804a21e ->
\x1e\xa2\x04\x08.
Summarizing our byte stream so far: CODE-- \x90AAAAAAAA Hellooo
AAAAAAAAAAAAAAA \x80\x96\xff\xf7 \x46\x96\xff\xf7 \xb8\x96\xff\xf7 \x1e\xa2\x04\x08.
Final Byte Stream
The last bytes of the data stream contain the printed instructions and the resolved addresses of
the puts:
\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x9
0\x90\x90\x90\x90\x90\x90\x90\x90\x83\xec\x0c\x68 \x61\x96\xff\xf7 \xe8
HelloooAAAAAAAAAAAAAA \x80\x96\xff\xf7 \x46\x96\xff\xf7 \xb8\x96\xff\xf7
\x1e\xa2\x04\x08.
Injection
Using the above byte stream on a Python client.

B.1 Static Malware Analysis Report: Environment Design and Procedures

Introduction
Static malware analysis is an important part of cybersecurity since it allows you to examine
malware without having to execute it, knowing its subtleties and potential consequences. This
study details the environment setup and techniques for static malware analysis, with a focus on
an unidentified infection that may be operating on Windows 10.
Environment Design
Secure Analysis Environment
Virtualization Mastery: Virtualization Mastery: Using the advanced features of VMware or
VirtualBox, we create an impenetrable fortress of analysis, shielding our immaculate Windows
10 virtual PC from malware's evil intentions.
Network Segmentation Artistry: By performing thorough network segmentation, we limit
malware's illicit communication inside the limits of our analytic environment, safeguarding the
integrity of our operating architecture.
Arsenal of Analysis Tools
IDA Pro: Unraveling the Mysteries of Code With IDA Pro, we can navigate the labyrinthine
code structures, revealing the dense tapestry of assembly instructions that constitute the core of
the infection.
CFF Explorer: Using the power of CFF Explorer, we dive deep into the heart of Portable
Executable (PE) archives to uncover hidden treasures of real and documented files..
Hex Editor HxD: Leveraging the power of the hex editor HxD, our process drills down into file
headers and metadata, shedding light on the dark depths where malware hides its secrets.
Detect It Easy: The Beacon for File Type Identification: Using Detect It Easy as our guiding
light, we journey the tumultuous seas of report sorts, charting our path thru the stormy seas of
malware obscurity.
Procedures for Static Malware Analysis
File Type Identification
Tools Used:
Detect It Easy.
Hex Editor HxD.
Procedures:
Employ Detect It Easy for swift report type identification, go-referencing with Hex Editor HxD
for file header scrutiny.
File Inspection
Tools Used:
Exiftool.
Exeinfo PE.
UPX.
Procedures:
Utilize exiftool for metadata inspection, Exeinfo PE to uncover capacity packers and cryptors,
and UPX for unpacking if necessary.
String Analysis
Tools Used:
strings2.
Pestudio.
FireEye Labs Obfuscated String Solver (FLOSS).
Procedures:
Strings2 and Pestudio are used to extract ASCII and Unicode strings, with FLOSS being used for
obfuscated strings.
Fingerprinting
Tools Used:
HashMyFiles.
VirusTotal.com.
Procedures:
Calculate MD5 and SHA-256 hash values with HashMyFiles, cross-referencing against
VirusTotal.com for malware identification.
Static Analysis Tools
Tools Used:
PEiD.
PEview.
CFF Explorer.
Procedures:
Examine PE files with PEiD, PEview, or CFF Explorer to check the API classes, functions, and
libraries that were imported.
Disassembling and/or Decompiling
Tools Used:
IDA Pro.
Procedures:
Disassemble executable code with IDA Pro, analyzing assembly patterns and control flow.
Decompiling capabilities offered by IDA Pro aid in understanding complex code structures.
Comparing and Classifying Malware
Tools Used:
Ssdeep.
Python3.9 pefile module.
YARA.
Procedures:
Conduct fuzzy hashing with ssdeep for similarity analysis. Utilize Python3.9 pefile module for
import and section hashing. Employ YARA rules for pattern identification and classification.
Expected Outcomes
Malware Type Determination
Identify the malware type, ranging from ransomware, trojans, worms, to potentially more
sophisticated forms such as rootkits and spyware. Through deep analysis of code structures and
behavioral patterns, establish a comprehensive understanding of the malware's classification.
Potential Behavior Identification
Uncover potential actions orchestrated by the malware, including but not limited to network
communication, file manipulation, registry changes, privilege escalation attempts, and payload
delivery mechanisms. Through meticulous examination of code snippets, system calls, and API
interactions, discern the malware's behavioral profile.
IOCs Extraction
Extract Indicators of Compromise (IOCs) for both network and endpoint detection. By isolating
peculiar patterns, signatures, and artifacts within the malware, compile a comprehensive list of
IOCs to enhance threat detection capabilities and fortify the organization's cyber defenses.
Packing/Obfuscation Analysis
Determine if the malware is packed or obfuscated, potentially revealing evasion techniques
employed by threat actors to evade detection and analysis. Through specialized tools and manual
inspection, unveil the layers of protection surrounding the malware, unmasking the intricate
methods used to cloak its true nature.

B.2 Static Malware Analysis (Analysis of needle3.exe and job.dll)

1. Use Detect It Easy to identify file types.

2. Use Detect It Easy to extract metadata and Exeinfo PE to detect Packers and Cryptors.
3. Use BinText to extract ASCII and Unicode strings from golf.exe.
4. Utilize static analysis tools (peframe) and disassemble golf.exe with IDA Pro to identify
any anomalies.
File Type Identification
Using Detect. The file types of needle.exe and job.dll are easily identifiable.
Needle.exe:
File Inspection
Detect It Easy is used to find metadata and check for any packers or cryptors.
Jobb.dll:

Extract ASCII & Unicode Strings

Using BinText, pestudio, and/or string2 to examine strings on a Windows 10 virtual machine.
0000000D13A0 0000E00D13CD 0 entry
0000000D1420 0000E00D144D 0 user_name
0000000D1430 0000E00D145D 0 user_name_size
0000000D1500 0000E00D152D 0 dllLibFullPath
0000000D1574 0000E00D15A1 0 IEUser
0000000D1580 0000E00D15AD 0 user is bad
0000000D1590 0000E00D15BD
0000000D15C0 0000E00D15ED 0 [x] Cannot find process %s
0000000D15E8 0000E00D1615 0 [*] Found process %s(PID = %d) 0 user is good
0000000D15A0 0000E00D15CD 0 explorer.exe
0000000D15B0 0000E00D15DD 0 c:\jobb.dll

0000000D1610 0000E00D163D 0 [x] Cannot get full path to %s

0000000D1638 0000E00D1665 0 [*] DLL library %s was successfully found
0000000D1670 0000E00D169D 0 [x] Cannot open process with id %d
0000000D16A0 0000E00D16CD 0 [x] Cannot allocade memory for DLL-library
0000000D16D8 0000E00D1705 0 [*] Allocated %d bytes at %#08x region
0000000D1708 0000E00D1735 0 [x] Cannot write process memory
0000000D1730 0000E00D175D 0 LoadLibraryA
0000000D1740 0000E00D176D 0 kernel32.dll
0000000D1750 0000E00D177D 0 [*] Starting remote thread at process %s(PID = %d)
0000000D1790 0000E00D17BD 0 [-] Cannot create remote thread in process with id %d
0000000D1828 0000E00D1855 0 Stack around the variable '
0000000D1848 0000E00D1875 0 ' was corrupted.
0000000D1860 0000E00D188D 0 The variable '
0000000D1870 0000E00D189D 0 ' is being used without being initialized.
A0, 0000000D18C0, 0000E00D18ED, 0. During a function call, the ESP value was not stored
correctly. Because of this, it is common to see functions with different calling conventions being
invoked using function pointers that have different calling conventions.
A0, 0000000D19D0, 0000E00D19FD, 0. Unfortunately, data was lost due to a cast to a smaller
data type. You should use the appropriate bitmask to conceal the cast's origin if this was
intentional. To illustrate:
0000000D1A79 0000E00D1AA6 0 char c = (i & 0xFF);
0000000D1A90 0000E00D1ABD 0 Changing the code in this way will not affect the
quality of the resulting optimized code.
0000000D1B28 0000E00D1B55 0 Stack memory was corrupted
Jobb.dll:
000000000AC8 000000000A55 0 VirtualAllocEx
000000000ADA 000000000A67 0 WriteProcessMemory
000000000AF0 000000000A7D 0 CreateSemaphoreA
000000000B02 000000000A8F 0 KERNEL32.dll
000000000C0A 000000000B97 0 AQAPRQH1
000000000CB2 000000000C3F 0 AXAXH
000000000CBA 000000000C47 0 YZAXAYAZH
000000000CCA 000000000C57 0 XAYZH
000000000CD9 000000000C66 0 ws2_32
000000000CF6 000000000C83 0 {{{{ATI
000000000D83 000000000D10 0 j@AYh
000000000DB9 000000000D46 0 }(XAWYh
000000001C00 000000001B8D 0 Local\tFXPD9P69t0YRk8ONCPs
000000001D10 000000001C9D 0 Local\xdLfRqJGKb3sEiGVYdW2
000000001E18 000000001DA5 0 rundll32.exe
00000000004D 00000000004E 0 !This program cannot be run in DOS mode.
Spot Anomalous Aspects of needle.exe and job.dll
Import libraries, imported functions and API calls

ADVAPI32.dll

GetUserNameA

KERNEL32.dll
CloseHandle GetConsoleMode GetProcAddress
CompareStringW GetConsoleOutputCP GetProcessHeap
CreateFileW GetCPInfo GetStartupInfoW
CreateRemoteThread GetCurrentProcess GetStdHandle
CreateToolhelp32Sna GetCurrentProcessId GetStringTypeW
pshot

DeleteCriticalSection GetCurrentThread GetSystemInfo

EncodePointer GetCurrentThreadId GetSystemTimeAsFileTime
EnterCriticalSection GetDateFormatW GetTimeFormatW
EnumSystemLocales GetEnvironmentStrings GetUserDefaultLCID
W W
ExitProcess GetFileSizeEx HeapAlloc
FindClose GetFileType HeapFree
FindFirstFileExW GetFullPathNameA HeapQueryInformation
FindNextFileW GetLastError HeapReAlloc
FlushFileBuffers GetLocaleInfoW HeapSize
FreeEnvironmentStrin GetModuleFileNameW HeapValidate
gsW

FreeLibrary GetModuleHandleA InitializeCriticalSectionAndSpi

nCount

InterlockedFlushSList LCMapStringW InitializeSListHead

InterlockedPushEntry LeaveCriticalSection Process32First
SList
IsDebuggerPresent LoadLibraryExW Process32Next
IsProcessorFeaturePre MultiByteToWideChar QueryPerformanceCounter
sent

IsValidCodePage OpenProcess RaiseException

IsValidLocale OutputDebugStringW ReadConsoleW
RtlCaptureContext SetStdHandle WriteConsoleW
RtlLookupFunctionE SetUnhandledException WriteFile
ntry Filter

RtlPcToFileHeader TerminateProcess WriteProcessMemory

RtlUnwind TlsAlloc
RtlUnwindEx TlsFree
RtlVirtualUnwind TlsGetValue
SetConsoleCtrlHandl TlsSetValue
er
SetEnvironmentVaria UnhandledExceptionFilt
bleW er

SetFilePointerEx VirtualAllocEx
SetLastError VirtualQuery

Exported functions and/or API calls

Job.dll
DllEntryPoint

Static Analysis With VirusTotal

Jobb.dll:
Static Code Analysis
Needle3.exe:
First the needle3.exe is checking the present user name with GetUserNameA.
According to the given user, it stops himself or executes itself continuously.

The code then verifies that it is not currently executing in the debugger. If so, it will come to an
end on its own.

needle3.exe locates explorer.exe & takes it’s process-id.

If explorer.exe is identified, it uses the GetFullPathNameA API call to obtain the complete path to
job.dll. If successful, the complete path to job.dll will be saved in the DLL Path.

The OpenProcess API method is used to retrieve the process handle of explorer.exe via its PID.
Following a successful handle to explorer.exe request, a VirtualAllocEx API call is used to allocate
memory.

Using the WriteProcessMemory API function, the job.dll is written to the base address of memory
that has been allotted inside of Explorer.exe.

After job.dll is successfully written to explorer.exe’s memory, explorer.exe uses the

CreateRemoteThread API function to establish a new thread, with LoadLibrary as the start
address.a base address job parameter and an exposed kernel32.dll function.Written memory of dll.
The explore.exe process is being injected with a DLL by Needle3.exe. It suggests that the
application fits the definition of a Trojan, more precisely a DDL Injector.

B.3 – Static Malware Analysis (Analysis of golf.exe)

1. Detecting file types using Detect It Easy
2. File review for application Find out Extracting metadata and searching for signs of
packers et cryptors is a breeze.
3. Use programs like BinText to extract ASCII and Unicode strings that are contained in
golf.exe.
4. Use IDA Pro to disassemble golf.exe and the static analysis website VirusTotal to
identify any unusual features.
File type Identification

Discover the golf.ex file type and more with Detect-It-Easy.

File Inspection

Use Detect It Easy to extract all of the metadata and search for any packers or cryptors that may
have been utilized.
Filename golf.exe
No. of Sections 0x0003
Import DLLs mscoree.dll
No. of Imported Functions mscoree.dll(1)
Base_Address 0x00400000
Entry_Point Address 0x00402dbe
Extract ASCII & Unicode Strings

Using BinText, pestudio, or string2, examine the strings on a Windows 10 virtual machine.

000000000F34 000000402D34 0 C:\Users\Kenny Sanderson\code\golf\obj\Debug\golf.pdb

000000000FA0 000000402DA0 0 _CorExeMain
000000000FAC 000000402DAC 0 mscoree.dll
0000000010D4 000000402ED4 0 ws2_32
0000000014DF 0000004042DF 0 <?xml version="1.0" encoding="UTF-8"
standalone="yes"?>
00000000151A 00000040431A 0 <assembly xmlns="urn:schemas-microsoft-com:asm.v1"
manifestVersion="1.0">
000000001565 000000404365 0 <assemblyIdentity version="1.0.0.0"
name="MyApplication.app"/>
0000000015A7 0000004043A7 0 <trustInfo xmlns="urn:schemas-microsoft-
com:asm.v2">
0000000015DF 0000004043DF 0 <security>
0000000015EF 0000004043EF 0 <requestedPrivileges xmlns="urn:schemas-microsoft-
com:asm.v3">
000000001635 000000404435 0 <requestedExecutionLevel level="asInvoker"
uiAccess="false"/>
00000000167C 00000040447C 0 </requestedPrivileges>
00000000169A 00000040449A 0 </security>
0000000016AB 0000004044AB 0 </trustInfo>
0000000016BB 0000004044BB 0 </assembly>
000000000CA8 000000402AA8 0 created by kdawg/vim squad!! If you want to find us
you know what to do..
000000000D3E 000000402B3E 0 golf.exe

Spot Anomalous Aspects of golf.exe

Import libraries, functions, and API calls

mscoree.dll
_CorExeMain

Static Analysis using VirusTotal