DEV Community: Raj Madisetti

Fraudulent Resource Consumption Attacks and a Gatekeeper Solution

Raj Madisetti — Wed, 17 Sep 2025 20:38:52 +0000

Hello cyber enthusiasts and professionals,

Today, I will be presenting the persistent threat of Fraudulent Resource Consumption (FRC) attacks and a proposed Gatekeeper solution below.

Problem

Fraudulent Resource Consumption (FRC) attacks are a stealthy, yet prevalent threat to Cloud Service Providers with a goal to exploit unattended vulnerabilities and deplete CSP resources. These attacks aim to take advantage of the pay-per-use algorithm that most Cloud Service Providers such as Amazon Web Services and Microsoft Azure use. FRC attacks involve an attacker covertly gaining access to an unsuspecting Cloud user’s account and setting up automated fraudulent resource requests (botnet) in order to siphon network resources for personal gain or malicious intent. Damages to CSP’s are based on the utility pricing model, the attacker’s skill level, and motivation.

FRC attacks are extremely important issues to address for Cloud users and Cloud Service Providers alike. They can critically disrupt organizational operations by dominating bandwidth and storage which can significantly slow or shut down Cloud servers. If servers are impacted heavily, it can lead to serious financial losses along with legal implications if contracts with private businesses are involved. Oftentimes, these attacks can also serve as distractions to lure attention away from more probing security threats such as data theft and network infiltration. Therefore, we should be diligent to implement a quick and methodical solution to Fraudulent Resource Consumption attacks in order to completely remove the problem.

Solution

This blog aims to introduce an effective solution to this FRC problem using a Gatekeeper medium in order to filter user requests to a Cloud service. This Gatekeeper can be used as another form of authentication in order to sanitize each Cloud request to verify its source and priority. If a user cannot be verified, its requests will be assigned to the lowest possible priority and will be severely limited as to not incur any significant FRC costs. In essence, we will allow normal and verified traffic to pass through efficiently through the Gatekeeper while clamping down on questionable Cloud requests. This will, in theory, eliminate the entire threat of FRC attacks in our Cloud model.

Experimental Approach

Normal request traffic, along with a simulated FRC (Fraudulent Resource Consumption) attack, was sent to an endpoint with and without a gatekeeper mechanism. The simulation involved ten trials of sending ten minutes of normal traffic at 200 requests per minute, five minutes of elevated traffic at 300 requests per minute, and another ten minutes of normal traffic to invoke Lambda functions, both with and without the Gatekeeper. The graphs were analyzed in Amazon Web Services (AWS). Both graphs showed noticeable peaks during the middle five minutes. The effectiveness of the Gatekeeper was measured by the reduction in the average requests per minute (RPM) of that peak with a clearly defined start and end time. The experiment is considered successful if the Gatekeeper reduces the average RPM of the peak by 70% throughout the ten trials.

The Gatekeeper proof of concept (POC) is a Python application with a client and server side. The client side sends requests with a payload (function name with user priority, region, and path) to the server on behalf of a predetermined number of users. The server side processes the requests from the client and executes them based on function priority. If a user has a low priority, their requests will be limited and will take longer to execute. This mechanism reduces the FRC peak for the Gatekeeper. A Python algorithm was used to send normal and FRC traffic to a Lambda function endpoint in AWS. CloudWatch Analytics was used to produce accurate line graphs to track function invocations as a metric for requests per minute.

Metrics for Evaluation

To evaluate and analyze the performance we can consider the following metrics:

Requests per minute (RPM): Measures the rate of requests being sent.
Response time: Time taken to get a response from the server.
Success rate: Number of successful responses versus the total number of requests.
Error rate: Number of failed requests.
Rate limit hits: Number of times the requests are rate-limited.
Retry count: Number of times requests are retried due to rate limiting.
Latency: Time delay between sending a request and receiving a response.
System load: CPU, memory, and network usage on the server handling the requests.

Large Language Models for One-Day Vulnerability Detection

Raj Madisetti — Tue, 16 Sep 2025 20:51:53 +0000

Hello fellow cybersecurity professionals and enthusiasts,

In this article, I will share my graduate capstone project titled Large Language Models for One-Day Vulnerability Detection that details an innovative penetration testing framework that incorporates natural language processing and large language model (LLM) driven multi-agent systems to optimize one-day vulnerability detection with an accuracy of 89.5% and a runtime of less than 30 seconds.

Problem

New software vulnerabilities are discovered and dis-
closed daily through Common Vulnerabilities and Exposures (CVE) records, which provide standardized documentation of these flaws. Once publicly accessible, these are known as one-day vulnerabilities. Despite disclosure, many systems remain unpatched during critical windows of exposure, allowing adversaries to exploit these flaws before organizations can mitigate them. Modern enterprises maintain expansive digital footprints, making timely vulnerability mitigation essential. Delays in patching one-day vulnerabilities can lead to data breaches, operational disruption, and financial losses. The core issue lies in the latency between the disclosure of CVEs and remediation, often due to insufficient automation and slow, manual vulnerability analysis. Normally, a team of cyber security experts is required to extensively experiment on a target endpoint to detect all potential vulnerabilities. Once an exposure is identified, a patch is deployed with a corresponding Common Vulnerabilities and Exposures (CVE) report. These reports contain critical information on the selected vulnerability, effects, mitigation strategies, and enumerated examples. This can be tremendously helpful for security teams in recognizing potential bugs within their own complex systems, but it can also pinpoint vulnerable attack surfaces that threat actors can distinguish. As faults eventually slip through undetected without the necessary immediate response time, there can be a considerable time frame in which an attacker can have the exploitational advantage. There is a particular need for an efficient and powerful tool that can scan intricate computer applications and output significant weaknesses and relevant techniques to repair them. In this paper, I will discuss an exceptional penetration testing solution to this urgent challenge that harnesses the capabilities of large-language models (LLMs).

Solution and Proposed Methodology

The multi-agent LLM workflow will be explored as shown the figure below in which each agent handles a segment of penetration testing on a target. Furthermore, a target in the case of this experiment is defined as a purposefully vulnerable website (OWASP Vulnerable-Web-Application and Acunetix VulnWeb) in which the LLMs will investigate known potential problems and report back to the user.

There will be an initial Exploration Agent in which a target is specified and all elements of the target will be analyzed, such as input fields and endpoints. Then, a Supervisor Agent will determine in which areas the vulnerabilities are and the CVEs associated with these particular vulnerabilities. When an attack type is determined, there will be Vulnerability-Specific Agents that deal with and test certain types of cyber security attack, such as SQLi and XSS that extract information from these CVEs. Lastly, the Fuzzer and Executor Agents will produce and test payloads in order to achieve successful exploitation. At the end of the testing, there will be a detailed output report listing the weaknesses in the target and the best methods of how to fix these vulnerabilities. In previous solutions, GPT-4 achieves a success rate of 87%, while all other LLM models achieve 0% across the board. My goal for this project is to attain a success rate greater than 87% in identifying one-day vulnerabilities to help ensure a more secure software ecosystem with proactive and reactive cyber security analysis for web-based systems.

In terms of grading the performance of the LLM, the purposefully vulnerable website will have a disclosed number of vulnerabilities which will be compared to the comprehensive report published by the multi-agent system at the end of each trial run.

Compare the number of true positive vulnerabilities detected by the system with the known vulnerabilities of each testbed.
Measure precision, recall, and false positives to evaluate effectiveness.
Assess time-to-detection and compare with manual testing methods.

The experiment will demonstrate not only how many vulnerabilities are found, but also how effectively and quickly the system can identify one-day vulnerabilities after disclosure, thus offering empirical support for the claim of improved cyber security readiness. The Penetration Testing System will utilize GPT-4o-mini by Open AI and LangChain/LangGraph for the Multi-Agent system approach. LangGraph allows for the exchange of information and improvement over time between stages of the workflow.

Multi-Agent Workflow

Multi-agent systems benefit significantly from direct collaboration between agents. To fully leverage this capability, an advanced conversational framework was designed that enables seamless inter-agent communication. By temporarily suspending centralized control, the system efficiently manages transfer requests, which improves context sharing and interaction between agents. This approach theoretically enhances operational efficiency and reduces unnecessary LLM calls, thereby reducing associated costs. This approach improves execution speed and accuracy by breaking down tasks into smaller components. Each agent is equipped with a customized prompt, a defined output schema, and a subset of documents that exemplify SQL Injection or XSS attack types.

It is recognized that one-day vulnerabilities may include previously unidentified signatures, which differ from the well-established patterns typically detected. This makes it particularly challenging for a team of specialized, task-specific agents to accurately identify them. To address this, the methodology is divided into two core components: one sub-team focuses on known vulnerability signatures provided from given CVE reports, but enhanced with new elements, while the other sub-team concentrates on input randomization and execution.

Implementation

The structure is built on LangGraph's multi-agent design pattern, enabling the agent's language model to iteratively loop until a solution is found or a predetermined number of steps is exceeded. The LangGraph Python library permits each agent in the "chain" to transmit messages and contextual knowledge seamlessly. Open AI's GPT-4o-mini model was used in this architecture as it is inexpensive along with providing cutting-edge abilities.

Testing

In order to evaluate the performance of the multi-agent system, a testing environment must be established. If an arbitrary target URL is provided and the LLMs generate a tailored output that detects the SQL Injection and XSS vulnerabilities on the site, there is no method to confirm the validity of the identified vulnerabilities if I do not have access to the underlying code of the website. In this case, purposely vulnerable websites were used as targets in order to preemptively know the confirmed number of SQL Injection and XSS vulnerabilities on each page. This information is then compared with the multi-agent system vulnerability assessment in order to grade its accuracy. The testing applications chosen for this project were Acunetix VulnWeb and OWASP Vulnerable-Web-Application as shown in the figures below.

Evaluation

This section addresses the results, costs, and comprehensive findings regarding the performance of the multi-agent LLM penetration testing framework.

Trials and Cost

Nine trials were conducted on the Acunetix and OWASP targets to gauge the accuracy and efficiency of the LLM system. OWASP SQLi Levels 1-4, OWASP XSS Levels 1-4, and Acunetix VulnWeb were chosen as test cases for thorough evaluation. For each trial, the LLM model was given a target URL and expected to output the vulnerabilities detected on the site with descriptions and security recommendations. The duration of each trial was also measured to assess the system's speed.

In terms of use in the testing phase, GPT-4o-mini incurs an inexpensive cost of $0.15 per million input tokens and $0.60 per million output tokens. The number of steps accumulated in each trial corresponds to the communication between agents. Although full screenings can lead to higher runtime and costs, the added expense is close to insignificant. For example, a trial that steps 100 times will only cost $0.12, so this approach offers an efficient method to identify one-day vulnerabilities and software exploits.

Effectiveness of the Architecture

The LLM-based multi-agent system identifies SQL Injection and XSS vulnerabilities in a target URL with an accuracy of 89.5% in an average trial time of 27.2 seconds. It provides the following:

Elements Detected
Vulnerabilities Detected
Location Detected
Possible Mitigation Strategies
Fuzzing Payloads to Exploit Input Fields
Findings from Controlled Execution
Summary of Actions Taken (Final Report)

The system delivers a complete and in-depth cyber security analysis of the website for users to process and, in turn, implement critical security improvements to protect against future breaches. Furthermore, the previous goal of an accuracy percentage greater than 87% has been satisfactorily exceeded by 2.5%.

Limitations

The language-model-driven agent network excels in generating accurate and extensive responses to support in cyber security defense operations. Its primary objective of recognizing potential threats in browser-based applications is realized. However, there are drawbacks and limitations in the current implementation of the application that, if amended, will enhance its overall promise as a solution for the future.

LLM Hallucinations

The figure below illustrates an agent transfer error that occurred sporadically due to confusion and sidetracking between nodes that can be attributed to LLM hallucinations. Conversations between the Exploration, Fuzzer, and Executor agents would occasionally derail, leading to an increased number of wasted steps in the output that failed to contribute new information to the vulnerability report until the application would error out, as indicated in the figure. This would happen very rarely in this framework, as opposed to prior solutions that were substantially affected. Unfortunately, issues of this sort are inherent to LLM-based platforms, and remedies would only come with improvements to GPT-4o-mini or the emergence of another economical and robust solution.

Narrow Attack Coverage

The multi-agent architecture as of now only covers SQL Injection and Cross-Site Scripting vulnerabilities. This is another hurdle that must be overcome for practical implementation. Web-based applications are not limited to SQL Injection and XSS exploits, so the scope of the project must be broadened for future iterations of the design. This involves developing more nodes and specialized prompts to include more types of cyber security threats for a broader security assessment.

Conclusion

This paper presents a machine learning-based optimized security testing framework that uses Large Language Models (LLMs) to autonomously parse and examine CVE records supplemented by specialized AI agent review. The LLM agent network is designed to offer an organized and effective approach to identifying one-day vulnerabilities through extensive testing. Through meticulous development and trial verification, this approach has improved the accuracy and efficiency of LLM results compared to previous LLM security systems. Therefore, it establishes a feasible and versatile solution to detect and address software vulnerabilities before or, in more critical stages, after exploitation. With a roadmap for future enhancements and corrections already in place, this robust and adaptable LLM multi-agent system demonstrates the capability to be a valuable resource within the cyber security domain.

MySQL: Client and Server Model Databases

Raj Madisetti — Tue, 27 Nov 2018 15:14:31 +0000

Hello fellow Javascript coders,

In this article, we will be discussing MySQL which is a very popular database management system based on a client-server model. To get a perspective on how useful and widespread this way of structuring application is, we can take a look at the many popular webs apps that you and I use everyday including YouTube, PayPal, Google, Twitter, and Facebook. All of those platforms use MySQL to structure the different and countless amounts of data that they send and receive to and from every user on their websites.

First, let's explore what a MySQL database is. MySQL is a database management system that can run on any platform (Linux, MacOS, and Windows) and is based on SQL (Structured Query Language). MySQL runs on the client-server model which means that the MySQL server can send client interfaces to multiple users simultaneously. These interactions with the server allow the client to send individual SQL statements in order to garner a response to their user interface. These SQL statements include ADD, DROP, INSERT, and UPDATE and can be used to adequately navigate through the database and perform a desired action on each entry.

If any random client could establish a connection with a MySQL server, there could be a potential security breach if the client had malicious intent on sabotaging the server. Luckily, MySQL has security features built in to prevent the threat from happening. MySQL uses a host-based verification system that uses access privilege and passwords to keep out anonymous dangers to the server.

Using AJAX in Conjunction with MongoDB

Raj Madisetti — Thu, 15 Nov 2018 01:05:02 +0000

Hello fellow Javascript coders,

In this article, we will be discussing how to implement AJAX calls into your full-stack web application that incorporates a MongoDB database.

First of all, AJAX is a method in jQuery that allows a program to send and receive data from a server (i.e. MongoDB) simultaneously without even refreshing the page. Thus, AJAX is very important for implementing applications with buttons or input from the user since it can be used in functions that are responsible for rendering text or data to the page.

Next, let's implement AJAX into an application. We need to require all of the relevant packages in the server.js or a differently named file that connects the mongoose database to your api and html routes. The file should look similar to this:

const express = require('express');
const bodyParser = require('body-parser');
const mongoose = require('mongoose');

const PORT = process.env.PORT || 3000; // any port number is acceptable

// Initialize Express
const app = express();

// Use body-parser for handling form submissions
app.use(bodyParser.urlencoded({ extended: true }));
// Use express.static to serve the public folder as a static directory
app.use(express.static('public'));

mongoose.connect('mongodb://localhost/[name of application database]', { useNewUrlParser: true });

// Routes
// API Routes (require from routes folder and pass in Express app)
require('./routes/api-routes')(app);
// HTML Routes (require from routes folder and pass in Express app)
require('./routes/html-routes')(app);

// Start the server
app.listen(PORT, function() {
console.log(App running on port ${PORT});
});

Now, the preliminary packages are required if they weren't already. Next in a different js file, you can create functions that accesses your mongoose routes such as GET, POST, or DELETE using AJAX. Here is an example of how to formulate a render function that gets data from a mongoose database and displays it to the page:

const render = function () {
$.ajax({ url: '/[put your route here]', method: 'GET' })
.then(function (data) {
let htmlstr = '';
data.forEach(element => {
htmlstr +=<h1 class="content">${element.content}</h1>;
});
$('#addStr').html(htmlstr);
})

.catch(function (err) {
console.log(err);
});
}

In this function, the AJAX call is using the databases GET routes and, for each data entry, it creates an html h1 element with the contents of the entry and adds it to an empty div.

Socket.IO: Real-Time Communication

Raj Madisetti — Wed, 07 Nov 2018 21:25:40 +0000

Hello fellow Javascript coders,

This article will explain Socket.IO and its advantageous use in full stack web applications as opposed to a traditional and lengthy database approach.

Firstly, Socket.IO is a Javascript library that facilitates real-time communication between clients and servers. This function is an integral component of any application that relies on data streaming, messaging, simultaneous group collaboration, and, even, gaming. Socket.IO is consisted of two parts that allow this instant communication: a client-side library in the browser and server-side library in Node.js. Sockets provide a two-way channel between these two sides of the interaction that allows clients to push to a server and receive an emitted response to all connected clients in a very short time. Because of this efficient functionality, many popular applications use it such as Microsoft Office, Trello, and Zendesk.

Now, in order to implement Socket.IO in your application, follow the next steps. First, we need to install express and socket.io using the node package manager (npm).
npm init
Enter yes to all of the questions the terminal asks. Then, run:
npm install --save express socket.io
This installs all the packages needed to correctly run Socket.IO. Next, we need to implement the application using the installed packages. In a .js file, use the following:
const express = require('express'); const app = express(); const server = require('http').createServer(app); const io = require('socket.io')(server); const socket = io();
Next, we need to tell the program what to do when a connection is established. Use this command:
module.exports = function(io) { io.on('connection', function(socket) { //SOCKET ROUTES socket.on('new-data', function(data) { console.log(data); } }) };
Now, whenever a connection 'new-data' is established, the data will log in the console. Nice!

This framework only outlines the beginning of a Socket.IO application, but there is so much more to do in terms of creativity and practicality.

The Function of Objects in Javascript

Raj Madisetti — Wed, 31 Oct 2018 17:18:47 +0000

Hello fellow Javascript coders,

This article will provide a clear and succinct explanation of the qualities of objects in Javascript and the various uses that each type of implementation has in creating the most efficient and least memory-intensive functions.

In its very definition, Javascript is a prototypal object-oriented language which means that everything in JS is an object of some type except for the primitive data types (number, string, and boolean). An object can have properties that can be called using dot notation. For example, we can take a look at this object:

var car1 = { company: 'Ford', model: 'Mustang', color: 'red', isLocked: false };

The object car1 has three properties company, model, and color and the line car1.model will, in turn, return the value 'Mustang'. Objects can also have methods which are functions that are specific to the object and are not defined above or outside its scope. We can take the same car1 object and add two methods paintBlue() and lock():

var car1 = { company: 'Ford', model: 'Mustang', color: 'red', isLocked: false, paintBlue() { this.color = 'blue'; }, lock() { this.isLocked = true; } };

Now that these methods are added in the car1 object, they can be called using dot notation just like any other property. For example, car1.paintBlue() will change car1.color from 'red' to 'blue'. Note, also, that the this keyword has to be used to allow the object to reference its own property and not change the scope of the function.

With the functionality of properties and methods, objects are very integral in creating helpful Javascript functions and, even, full-stack web applications.

MongoDB: Databases Made Simple

Raj Madisetti — Tue, 25 Sep 2018 23:23:43 +0000

Hello fellow Javascript and Node.js coders,

This article will teach you the basics of Mongo and MongoDB and its useful qualities.

Firstly, MongoDB is classified as a NoSQL database which means that it stores JSON (Javascript Object Notation) documents in any structure that a user wants. To illustrate its flexibility, each element of the database can possess different fields and the overall structure of the entire database can be always be modified. MongoDB organizes each document into larger collections using its dynamic "schema" which maps each document individually.

Because of this relative ease in dealing with all types of data, MongoDB is a widely-used database that shifts and molds itself to fit to Node.js applications that sometimes do not conform to a standard database approach which consists of a traditional row and column model in a table. MongoDB also has the ability of sharding which means that the database and quickly and efficiently distribute data across large groups of computers/machines. Additionally, MongoDB is a free open-source database program which appeals to the many developers on a budget and the program supports C, C++, C#, Javascript, Node.js, Java, PHP, Python, and many more languages.

To actually interact with the extensive database, programmers use the mongo shell Javascript terminal to interact with data and connect with another running instance of MongoDB server. First, a terminal window with the command mongod must be running and another terminal window must be used to develop and edit databases. In the other terminal window, the command mongo must be run. Then, one can create a database with db [name of database], then use [name of database]. To exit, you can either write quit() or pressing <CTRL-C>.