← All talks

BSidesROC 2024 - Exploit and Malicious - Olivia Gallucci

BSidesROC37:5590 viewsPublished 2025-03Watch on YouTube ↗
About this talk
This talk demystifies (legal) exploit development, providing attendees with a comprehensive understanding of how corporate and freelance hackers utilize open source software (OSS) for offensive purposes. Here, the audience will delve into the mechanics of exploit development using OSS. Additionally, participants will gain insights into the tools and platforms commonly employed in creating exploits, walking through a step-by-step development process. Real-world examples underscore the significance of incorporating OSS into cybersecurity practices and the potential consequences of neglecting this aspect. The final segment sheds light on the common misconceptions surrounding professional exploit development, and provides a nuanced perspective on the tools and techniques involved.
Show transcript [en]

Good morning. Everybody's head pops up. It's kind of like you're all little gophers. Uh I am pleased to present Olivia Galuchcci who will be your next speaker. She is an offensive security engineer, freelance penetration tester and security researcher. She is an undergrad student at the Rochester Institute of Technology, double majoring in cyber security and computer science and moni and minoring in free and open source software and freedom culture and ranks in the top 1% of her class. In addition, Olivia maintains a blog on security, open source software and productivity. Outside of cyber security, she enjoys competitive sailing, political debates clubs, and biographies of famous computer nerds. Welcome, Olivia.

All right. So, um, hi everyone. Welcome to my talk on malicious and sorry on exploit and malicious tool development utilizing open source software. So, statements I make in any media that uses this disclaimer reflect my opinions and do not reflect the views or policies of my employers, past or present, or any organization that I might be affiliated with. Additionally, any names I mention or software I mention in this presentation are not associated with me or my employers either. I'm giving credit for their work. As a quick introduction, hi, my name is Olivia Galuchcci. My background is primarily in the offensive security space. I started my career as a penetration testing consultant and then I moved to corporate red teaming for

around a year or so. I then switched to vulnerability research through a government contract with the Department of Homeland Security and SIZA. And then over the past year, I've been doing freelance malicious tool development and software development. I got into freelance because it's common to only do a fraction of the attack and reporting process when hacking in consulting and corporate settings. I really enjoyed one aspect of this process which is the focus of this talk. But my goal in freelance was to get better at every area of the attack and reporting process by doing every area of it myself. Also, I'm a student at RIT um studying computing security and computer science. Now, let's get into the talk.

Offensive security exists to identify and mitigate vulnerabilities within systems by simulating real world attacks to bolster defense strategies. The goal is for good hackers to find vulnerabilities before malicious attackers do. Since we know that cyber crime isn't going to stop anytime soon, understanding offensive development is critical to protect assets. So for this presentation, I'll be wording scenarios as an attacker because that's what my job is. The only difference is the end goal. Thus, when I say I'm trying to harm a system, remember I'm doing so with the intent of protecting it. Before we get any further, I also want to quickly define what I mean by open-source because I'm not talking about monetarily free or freedom

respecting software. So for background, what is free and open source software or FOS? The word free represents freedom as in free speech, not like free as in free of cost or free beer. In general, labeling a program as foss guarantees four freedoms that the source code is open for anyone to use, study share and modify. Foss is different from the term open source. Similar to the word natural on food packaging, open source is a vague term that does not guarantee any of the four freedoms. And for this presentation, I'm using an even broader definition of open source, which is to refer to all slightly readable software up to fullfledged freedom respecting FOs. This also includes open resources,

for example, exploit DB. So what are we talking about when we say exploit and malicious tool development? And what is the role within attacks? Well, it's all part of a process. And I think Casey John Ellis's example of getting punched in the face illustrates security vocabulary well in this context. When getting punched in the face, we know that the threat is the punch being thrown. The threat actor is the person who wants to punch you in the face. The attack surface is the size and shape of your face. While the risk is the likelihood of getting punched in the face plus the amount of damage caused if the punch lands. Here the vulnerability is your

inability to defend against the punch and the exploit is the fist. In other words, the weak the vulnerability is the weakness and the exploit is the weapon that harnesses that weakness. So what exactly are exploits? Exploits can be synonymous with any weapon. It could be a fist, knife, gun, bat, car, or a plastic spoon. In this context, a weapon is a piece of code that takes advantage of a vulnerability to carry out a specific action. When the fist is sorry, when the exploit is run or the fist is thrown, I can hopefully bypass security to gain unauthorized access or knock you down to steal your wallet. Vulnerabilities arise from various factors such as programming errors, misconfigurations, design flaws

or inadequate controls. So when we talk about exploit development, we're referring to studying those things to find or create harm. Now you might be wondering how does someone develop an exploit and how does it differ from standard vulnerability research and what's that process like? One reason why I wanted to do this talk is because these terms have no formal definitions and this is kind of terrible for people who are looking to buy and sell exploited services. Half the time people don't know what I'm talking about and the other half I don't understand what they want from me. So in this talk I want to explore what each of these roles are in my experience and encourage everyone to

think about how we can define these terms to become more industry standard. Most commonly exploit development starts with traditional vulnerability research. Although some people just do the development part which I'll get into in a bit. This research may be done through reverse engineering by analyzing software binaries or by feeding a uh sorry by analyzing uh software binary binaries or by fuzzing uh which is feeding a program with massive amounts of random or unexpected data. It also includes code auditing by studying source code or dynamic analysis by monitoring the software's behavior during runtime. This also includes debugging and instrumentation as well. Instrumentation refers to the process of adding code to a program to monitor its behavior. This behavior could include

like system calls, network traffic, memory access, and other programs of a other functions of a program's execution. Lastly, it could include threat modeling. And this is usually done to understand the systems architecture. Now let's explore exploit development. As I previously stated, exploit development starts by identifying and understanding the vulnerabilities within software. This can be done through various means including reverse engineering, code auditing, fuzzing, and other methods I mentioned in the previous slide. However, there's an edge case of vulnerability discovery though where engineers will literally create and push vulnerable code into an internal program that a corporation runs if they find the opportunity to do so. And I've seen this used as a way to prove that more co

coding tests and reviews need to be done throughout a company's or team's software development process. Then once a vulnerability is identified, the next step is to develop a proof of concept to demonstrate its existence and impact. And this proof of concept can literally just be a proof of concept or something that they actually plan to use to harm a system. This typically involves writing a small piece of code or crafting input data that triggers the vulnerability. Let's dive into the subcategory for a bit. Exploit proofs of proofs of concepts are one of the like best areas to see how open resources can be used. For example, exploit DB is a website that provides a collection of exploit shell code and

like vulnerable web apps and security reports. You can also download and add to it as well. I found it particularly helpful because of its ability to like filter and just sort data. So, if you want to sort by like version number, program name, or like even like date, like it's it's super easy to do and like very easy to use. I've also seen people use CX security. It's a blog maintained by one person, so I can't really like verify like all the things that like are put on there, but I've seen people use it. Lastly, we have GitHub. I think everyone here knows how to use GitHub at this point, but like I search GitHub

like a million times a day just to see if other people have done something before me and can save me a lot of time. Now returning to the exploit development process. After PC development, we design the exploit to take advantage of the discovered vulnerability. This involves understanding the systems architecture, memory layout, and behavior to craft a payload that can exploit the vulnerability and achieve a desired outcome such as gaining remote code execution, privilege escalation, or really any other thing that you'd want to do. Then we create the exploit's payload, which is the code or data that the exploit injects or executes on the target machine. Payloads are really cool and one of my favorite activities in school was a

rubber ducky payload workshop. A rubber ducky is a programmable USB which is used for keystroke injection attacks. And a payload um in this case a great example of that is like disabling volume controls and rick rolling the user at maximum volume until they turn the machine off. There's tons of payload examples on GitHub. Like if you just search like payload, like the top one I think has like 20k stars and then like the bottom one on the first page I think has like 11k stars. So like there there's a ton that are very famous and very fun. Payloads can vary depending on the exploit's goals such as spawning a shell, executing arbitrary commands, or establishing a backd dooror for future

access. Next, if we're lucky, we'll be able to test our exploits to ensure they work reliably. And this involves like debugging the exploits code, tweaking parameters, or redefining the payload. However, this is often very hard to do, especially if you only have limited information or cannot easily replicate the environment you're trying to break into. And I will say debugging and testing is also one of the trickiest areas because you often only have one shot before something is flagged. And at least in my experience, this is especially true in low latency networks or networks that don't have much variety to the traffic that's being sent through them. Then we may focus on obuscation and evasion to bypass security mechanisms

such as like antivirus detection or like intrusion detection prevention systems like all that type of stuff will sometimes employ techniques such as like code obuscation. Um, and even like sometimes like trying to encrypt something, which doesn't always work in the grand scheme of things if we're trying to retrieve certain information, but that that's one thing that's often done to just make the exploit harder to detect and analyze. Finally, we might document and share our research and learning with the security community. Um, this is usually done through, you know, exploit DB, Twitter, blogs or presentations. This helps raise awareness about whatever we found and also enables defenders to develop counter measures. Throughout the exploit development process, we almost always

have a set of responsible disclosure practices, ensuring that vendors have an opportunity to patch the vulnerability before anything's shared or if the vulnerability like could potentially be exploited maliciously. That hopefully solves that problem, too. Some exploit developers just focus on three to four areas of this process though. For example, vulner for example, vulnerability discovery is often rooted out of these jobs because you can often pay people performing, you know, automated scanning and like uh what's it called? Um automated scanning triaging much less than a software developer. Now, how does exploit development differ from malicious tool development? While exploit development focuses on crafting code to exploit vulnerabilities, malicious tool development encompasses a wider range of functionalities aimed at

facilitating various malicious activities including but not limited to exploit development. There's three main aspects to this which is like frameworks, customs and automation. Starting with frameworks. Sometimes we'll use or create platforms that have like a collection of pre-built pre-built exploits corresponding to vulnerabilities. These frameworks provide us with the ability to easily launch attacks against vulnerable systems without the need to develop these exploits ourselves. Some popular frameworks include metas-ploit, autosloit, pachu, router sploit, beef, and waf. Metas-ploit is one of the most widely and comprehensive exploit frameworks used. It offers a collection of exploits, payloads, auxiliary modules, and post exploitation tools. Metas-ploit is often used in conjunction with exploit DB as well. Autosloit automates the remote host exploitation by collecting targets

from showdan, census, and zumi with options for custom targets as well. It leverages selected metas-ploit modules for remote code execution and back connections. It also offers a proxy edition where you can like modify settings and a custom user agent. So for some context, Showdown is a search engine specifically designed to find connected devices and like including like computers, servers, cameras, printers, like really anything by indexing information from banners and metadata. Census is a platform that helps discover, monitor, and analyze devices that are accessible from the internet just by regularly probing every public IP address and popular domain names. Lastly, Zumi is a search engine similar to Showdan, specifically focused on discovering and indexing internet connected devices. These resources are

mostly paid though. So, since this presentation focuses on open resources, I wanted to mention this tool called I think it's called Ivra, like IV or something. I'm not quite sure how to pronounce it, but although I haven't done like a direct onetoone comparison, it it is technically an alternative to these options. Then we have PAU, which is an AWS exploitation framework. PCU allows users to exploit configuration flaws within an account using modules to expand its functionality. Current modules current modules enable a range of attacks including privilege escalation, backdoring users, and attacking vulnerable Lambda functions. Lambda functions refers to a serverless computing function that is hosted by AWS Lambda. Next, we have router sploit. Router sploit is ta t t t t t t t t t t

t t t t t t t t t t t t t t t t t t t t t t t t t t t t t tedred for embedded devices, featuring modules for exploits, testing credentials, scanning vulnerabilities, and really just everything else. It's pretty comprehensive. And then next we have Beef, which is a tool that's used to hijack web browsers using uh them as a launching point for various attacks. It can manipulate browser content, request permissions for device access, execute code, and deceive the user into running malware. This tool provides limited control over a user's browsers and enabling actions like tabning, which is where a tab redirects a user to like a fake login portal and the user would

then log in and you could capture their credentials. Lastly, we have WEF, which audits Wi-Fi networks with different types of attacks for WPA, WPA2, WPS, WP, like pretty much all of it. And then, um, it also helps with automated like cracking of passwords as well. Um, and yeah, and then outside of these frameworks, we might create exploits tailored to specific vulnerabilities, to target environments. these exploits are integrated into the malicious tool and it also just helps us exploit something a little bit more efficiently. But again, this is occasionally rare, especially if you're doing it outside of like a corporate setting because you often need something very uh specific in those settings. Whereas, at least for my

experience in freelance, using something a little bit more general has often been very helpful because it's it's usually just like found on the internet and it just works out of the box. In my experience, especially in like more of like corporate settings, this has been where I've like spent hours just reading like C or assembly code, modifying one to two lines, and then sending it off somewhere. However, I think SQL injection is more like one of the like more common examples of this where people have developed customs. Let's say like there's a web application with known security vulnerabilities in it is specifically like let's say like the login portal is vulnerable to an SQL injection.

We might create a custom exploit specifically like a custom like SQL command that would allow us to bypass authentication and gain unauthorized access to the system. The custom exploit code would typically involve just constructing an SQL payload and then sending it to the vulnerabil login form. The custom exploit again would be tailored to the specific vulnerability and it wouldn't normally be something that you would be using. Generally with the example of SQL injection, you're usually not getting like too specific because like there's only like, you know, so many that you can do commonly. To get even more specific, the 2017 Equifax hack was a very famous example of this where attackers utilize SQL injections as part of their attack

strategy. They exploited a vulnerability in Apache software which allowed them to execute SQL commands remotely on Equifax's web application. This vulnerability provided them with a foothold to access Equifax Equifax's systems, conduct reconnaissance, and ultimately excfiltrate sensitive data of 147 150 or so million Americans. Now, back to malicious tool development. Lastly, we might try to automate the process to make it easier to launch attacks. And almost like all of the ones that we covered previously accomplish that goal and you can find additional ones on GitHub too. Now you might be wondering where have there been problems in the past especially from like specific open source tools. So, back in the early 2000s, um, uh, back black, I

believe it's black orifice, not back, I think that was a typo, was an open- source remote administration tool for Windows, allowing control of the server from a distant client. It enabled functions from like file management to convert actions like keystroke logging. It al also operated very stealthily, often escaping detection from antivirus. It was used for a variety of attacks, including one where the people who built this program accidentally distributed CDs with malware on them already. And so they they did this at um I think I forget which Defcon, but they distributed these CDs at Defcon and then had to apologize for it because they didn't realize they had put malware on the CDs. The blame for its growth and popularity

was really given to its creators as well as Microsoft's lack security measures in Windows. Th this program really underscored the need to actually care about security in the early 2000s, especially just with how easy it was to upkeep and just keep embarrassing Microsoft. Uh metas-ploit is another common example that's caused harm. Um, one prominent example of this is a 2012 zeroday Java exploit that targeted two previously unknown vulnerabilities putting over a billion users at risk. The exploit was highly reliable and worked across multiple platforms and operating systems. At that time, Oracle claimed that over three billion users were running Java and a significant portion of them were running Java 7, which was like very vulnerable to

everything. And then prior prior to Oracle releasing patches, Metas-ploit just went and implemented this attack into Metas-ploit. And as a result, the people who had access to Metas-ploit could just like execute this attack on like wherever they wanted. And it caused a lot of harm. And it also was kind of a bad PR move for Metas-ploits. They were like, why did you do this? And then this instance really just illustrates how Metas-ploit's rapid dissemination of exploits can potentially aid attackers in compromising vulnerable systems, especially given that they did it before a patch was released. Lastly, we have impact. Impact is an open source Python library that provides a set of tools for crafting and manipulating network

protocols. It's widely used for network reconnaissance, exploitation, and post exploitation activities. In 2021, Impact was used by hackers to exploit several CVEes um for for various purposes including gaining initial access, lateral movement, and network exploitation. These CVEs were leveraged by the hackers to in install web shells and gain persistent access across a variety of victims Microsoft Exchange servers. Additionally, impact was used for network exploitation activities and the impact modules WI exec and SMB exec were specifically used. These tools utilize Windows management instrumentation. That's what the the WI stands for. and then server message block that that's what the SMB stands for to create semi-interactive shells with the target devices. Through these tools, the hackers were able to run commands on

remote devices utilizing the required Windows management protocols. The use of impact allowed these attackers to compromise credentials, move laterally within the network and ultimately just exfiltrate a lot of sensitive data from the victim's organizations. Additionally, a custom exfiltration tool named covealent stealer was employed to facilitate the exploitation of sensitive files on the victim's networks. Put simply, impact. It just really served as a like as pretty much the foundation for a lot of the of this attack and at various points throughout the process. And it really just shows how one tool can really be used to just damage the reputation of a multitude of companies and really create a lot of harm. Through these examples, you can

see there's a few instances where open source tools have proven to be problematic. However, it's important to remember that you can't fix bad systems without evaluating those systems. If malicious tools like these were not available, bad hackers would be writing their own tools anyway, and that would leave us good hackers unarmed and at a disadvantage. I think this quote by Marcus Ranom serves as a good bonus to malicious tooling, too. I I don't think it's always true, but it's something that kind of makes me smile a bit, especially given the increased reliance on open source as well as the increased reliance on bug bounty programs. Offensive security is more of a co-evolutionary process. Tools like

metas-ploit make it easier for people to exploit stuff, which puts pressure on them to harden the systems. It may force an immune response from the community that you would not have probably gotten otherwise. Now to wrap up and summarize this presentation, um we covered why offensive security matters, defined exploit and malicious tool development, learned about common open source resources and attack processes, and a few real world examples of where open source tools have been used to create real world malicious harm. If you notice, I did focus on how these open source tools created harm and very specific harm because one of the things that's very common within the security community or or some aspects of it is

like, oh, malicious tools are going to create harm. Yet, a lot of times people don't cover the specific harm that they've caused. And that kind of bothers me a little bit as someone who's an open source advocate because I've learned a lot from open source. I regularly use open source. A lot of companies regularly use open source. And it's a little bit misleading to be like, yeah, offensive tools are just harmful. And the idea of offensive tools just existing is going to inherently create harm without citing specific examples of it. And at this point, I hope these types of things are old news, but they're really not. Like, every time I check Twitter, there's usually like some

sort of thing just like bashing open source. But I think it's important to remember that these tools actually help us to protect networks. Also, um I know it's very small, but if you want to see my references, they're at the bottom of each of the slides, and I don't have a QR code like the last speaker to my slide deck, but I can post a link to like a Google Drive or something on the YouTube comments. So, thank you so much for attending my presentation and to all the volunteers that made Besides Rochester possible. um as well as my lovely friends who supported me throughout this

[Music] journey. Um does anyone have questions? So with a lot of the IPS that are out there, the open source uh seems to kind of be these type of things with those things seem to be kind of feeding those and keeping them grow. So would you say that if they started to start trying to get to a point where they start controlling these type of things or locking them down or removing them and might cause bigger issues for us to be able to detect these things being used in the wild is different. Um, I'm not quite sure if I understand the question, but I do think it's imperative to upkeep these tools, especially for like like IDs and IPS systems that are

using like any form of like machine learning and all of that because at least in my experience, harmful data has been used as a direct way to train these systems and when like you're generating this harmful data, right? it's making you know IDS and IPS machines much better. So I think you know these tools in a way like you suggested like really do help you know IDS and IPS systems. So any more questions? So it seems like um so from all like the research that you have done like a lot of degrees and also like learning a lot of new technologies and resources very fast. What do you think are some like key factors that contribute like your

success especially with like navigate your careers learning new languages and picking up topics very quickly? Uh calendaring um I I I really keep a very strict schedule. Um I really love academics. I love like my extracurricular activities. I love work as well. And being able to balance those things with my calendar is like the like if I don't have my calendar, like if I didn't have my calendar, I just would do nothing because I wouldn't remember what I have going on. So I just document everything that I have to do and I set up like repeated events and it just kind of keeps me on track so I always have something to do. I'm never bored and I

also get everything done. Yeah. So you were talking about open source and attack framework specifically. Do you think there's a what is the relative difference in good versus bad of open source versus if all of these tools were put behind? So, it's interesting you say that because there's some really good like paywalled services and paid walled frameworks and I I don't know and this is a question that's been repeatedly asked over and over and over again and I think in instances where like we saw where metas-ploit just like decided to you know push things into um like push unpatched you know vulnerabilities like just like into their program like It really does raise the question of

like in what like what is ethical here? What is just going to cause more harm than good? And I really don't know and I don't think we'll ever know because I don't think there are great metrics to, you know, analyze this. And a focus of this talk was like trying to find very specific use cases of where a specific malicious tool was 100% proven to have harmed a system. And that's often very hard to do it. When you see like news reports and stuff, every time a hack occurs, they often will never directly call out a tool. And when they do, it's usually something of, "Oh, this might have been used. This may have been

used." And that annoys me because it's like how do you know how do you know what you know AP40 is using? Like it really frustrates me when you know this these broad generalizations are being used. And so I don't think there's going to be a way to tell unless our like the way that we analyze networks after hacks occurs like drastically improves and we can put numbers on it. But I I just I don't I don't think there's a way currently. So question and then follow question. First one um for the issues that you mentioned with me releasing uh the exploits too soon. Do you know if this was in the uh free and open source

version or premium version? I believe it was in the free and open source version. Uh and so with these tools having the effect you said, what are your personal thoughts on the commercialization and regulation of these tools at a premium level aimed at corporations and government entities and should those same capabilities be extended to the civilian population? Um, I'm not entirely sure and cuz I feel like it depends on the tool itself and then how the like how the tool is also released to the public. Um, I think I think there's a lot of concerns around that like that are that are valid especially like when you talk about like government tools or like like I feel I

feel like that could do like a lot of harm really fast. So I I think it would be more tool specific. I will say though, as someone who's, you know, worked for corporations, I like to have more knowledge of what type of of attacks and what type of harm, you know, could be caused. And so, more knowledge in my experience is always better. So, I would like to know, but, you know, I'm sure other people with malicious tent would would also like to know.

So for ideological reasons, I like GPLV3. However, if you have different goals that are not driven by, you know, beliefs and stuff, uh, you know, you'll probably want like an MIT license or GPLV2. Um, there's there's a lot of great licenses. I I know a lot of people like the you know the Apache licenses as well because they want you know corporations to adopt their software. For for me I'm very ideologically driven.

Can you please request uh repeat your question louder?

No. Um I just it really frustrates me with this idea of like a corporation can take my work and then like not add on to it. I I think the way that, you know, science and innovation happens is by people sharing and building on top of each other. And so what I'm trying to do is to literally just force the innovation. I don't care if other people are making money. Like my my blog for example, you can take any content you want off my blog and not even site me. I don't care. But what I do require is that you also put like have that all that content also be open. I want people to add and build and innovate and I

don't care about the I mean I like money but like you know that's that's not what I'm going for. I want innovation to to be consistent. I want to make the world a better place and the whole idea of like we're going to have you know our program and then our company is just going to take it and you know do whatever with it and never you know advance the community forward is annoying. Um, any more questions?

almost everything I use throughout my entire career and education has been open source. Um like like almost everything it is very very rare. I mean there there's times where like I'll use like a corporate license of a product, right? But like the core like a burp suite, that's a great example. Like like there's that that's a thing, but like the core product itself is almost always open source. And the times where it hasn't been open source, it's because I've been developing something that is proprietary. But again, while I'm developing, I'm also using open source tools to do the development as well.

We're done. Congratulations on being one of the rare speakers that I I rehearsed a lot and I I'm very nervous, so I spoke a lot faster than I should have.

[Applause]

Um, you did great.