Overview

First and foremost, Packet Storm Security is an information security archive. Unlike other security sites and services, we host all the data. We curate descriptions and provide tagging alongside attribution and any available data. We believe strongly in digital archives. History dies in darkness and not having a record of prior problems can lead to history repeating itself. For anyone that has worked a security incident, you understand this need.

We shed light on security issues with daily updates and our archive goes back to the 1990s, back when government advisories warned of this new thing called "spam". We provide free open source tooling and scripts, exploits, advisories, whitepapers filled with research, and more. We are considered a raw intelligence source for many other commercial threat intelligence feeds. For those working in the information security industry, we are a foundational resource and a household name. We are referenced in many books, articles, and even have an entry in Webster's Hacker Dictionary, as crazy as that seems.

Want to see what headlines are affecting the world today?

Read our News section.

Want to see what new files came out today?

Check out the Files section.

Here's where we sit in the industry:



Our ethos

Sharing is caring

At Packet Storm, we are strong believers in humanity and helping the greater good. The Internet doesn't have borders so neither can the dissemination of security information. We all have to survive on this rock and the best way to do it is with the lowest stress level possible while managing triage. Everyone deserves to know when a vulnerability could affect their livelihood. When we share information, we build better together. We fix better together. And we learn quicker. This is how science works in every domain and it's critical to understand the importance of the work. We don’t subscribe to book-burning philosophies, delayed notifications, or censorship, because those trajectories are borne of malice and harm the broader tech community. This is why for any human browsing our site, there is free access with no strings attached. We do not track your movements or sell your data.

How Packet Storm is used

Below are some of the ways that the Packet Storm archive is leveraged.

Security research

Packet Storm offers not only a platform for researcher collaboration and sharing, but a haven for people to provide their findings without judgment. In this digital age, information sharing in a timely fashion is more critical than it has ever been. Those willing to share their findings and get the word out are the true heroes of the industry, as they do it for promoting awareness of the issue or necessity to patch, not for profit motives. It's noble and we respect the research community greatly.

Vulnerability awareness

Vendors are known for downplaying an addressed vulnerability and sometimes ignore patching altogether. We serve as a conduit for researchers to let consumers know of problems that could affect their security. Vulnerabilities are rarely a tomorrow problem, as hackers move fast and may already be in your network. The first step to addressing security issues in your entity is to be aware they exist.

Building tooling

Having worked in the industry for the past thirty years, our team understands that most security product solutions do not scale well when it comes to large environments. Engineers usually have to roll their own solutions and frequently leverage tools found here as a starting point. We have ended up being a resource that has helped a multitude of firms go from being a start-up to a billion dollar company.

Offensive testing

Whether you perform offensive testing in a corporate or government capacity, you will have no doubt leveraged Packet Storm at some point. We have many scanners and over 50,000 exploits that can be freely downloaded for whatever operation you have planned. Over the years many niche sites have tried to replicate the "exploit archive" aspect of our site, but they eventually all disappear as the work to keep it maintained never stops and providing a free service usually fails to cover the bills.

Threat intelligence

Whether referencing our news section or extracting telemetry from our API to enrich threat intelligence feeds, we act as a primary source for ingestion for many of the commercial products you see in the information security industry. We also offer API access directly at a far lower cost. Although you may get your security information through information feeds from other places, finding the actual relevant vulnerability details and exploitation vectors can be trying, until you end up clicking on a link that comes back to Packet Storm.

In addition to third party feeds, SIEMs, and other commercial data streams, MITRE uses us as a validation reference point to make CVEs public.

User experience

Becoming a user on Packet Storm is fast, free, and easy. Further, it gives you access to building collections of data, following activity of other researchers, bookmarking entries, adding social links, and multiple other features. Only an email account is required to sign up. If you have works in the archive and sign up with the same email address associated with the credit, your user profile will automatically link to your associated files.

Advertising

Our audience is niche. Our users require a level of technical understanding to make the best use of our systems. We are not a general news site, but rather the place where people in information security go on a daily basis to see the latest headlines. Our traffic hovers around 16 million individual page views monthly with about 4 million of those being bots that we block.

Many advertisers believe that social networking systems are the best place to advertise, but that only works if your audience is there. A vast amount of people in the security space do not make use of social networks as they comprehend how their information can be leveraged against them. It's good to be paranoid. But that makes advertising your security product or service just that much harder. We bridge that gap by providing cost-effective in-site advertising that takes under 60 seconds to publish. Our design ensures a secure implementation (e.g. no third-party javascript) and a guarantee of, at minimum, 10% of the site's traffic over a 30 day period. Our pricing is cost effective as well! You can read more here.

API access

Programmatic access to such a large datastore is critical for a myriad of reasons. If you work in a SOC, you can integrate our feeds into real-time analysis for issue tracking. If you provide a threat intelligence feed, you reference Packet Storm for new issues and any relevant telemetry for analysis. If you are building a security AI offering, you need a way to access the data at scale without getting hit by our guardrails. We have an extensive amount of rate limiting and guardrails put in place to fend off bots and automation. Please note, if you are a commercial offering making use of the site, you are required to use the API and pay for access. You can read more here. Commercial support of the site is what keeps it available as a resource.

Submitting entries

If you want your article, research, or otherwise added to the archive, we welcome it! We do not always accept everything, but we try to help in any way we can.

Things we usually do not accept are crime kits, malicious intent software only created to damage a system, or vulnerabilities in unique services that only affect the owner of that service. The reason we do not normally publish vulnerabilities in unique services is purposeful and it is not to say we won't eventually post about it. We try to focus on issues that affect multiple consumers of a code base.

For instance, if eXample CMS is being used by 10,000 companies, we need those companies to know about a remote code execution vulnerability that can be used to hack all of them. We may have watched eXample CMS downplay their vulnerabilities in their changelogs for years so their customers remained unaware.

But if a custom service at Widgets Social Network has a remote code execution vulnerability that affects their company's cafeteria menu, and they're running a unique code base they built, releasing that information does not benefit the public. Before submitting research in a custom service to us, we request that researchers work with the vendor and attempt to get commitments for patching. If you can provide relevant details of what was said when, it goes a long way with the public discourse.

There is a gray area, however. Not every situation is the same. If the vendor pushes back, ignores you, or otherwise puts their user base at risk as long as their systems are vulnerable, we will then publish it to help raise awareness. Further, if a vendor has addressed an issue but you still want the information published so their users are aware it even occurred, we can do that as well. If we believe the threat to the users of the service is so great that it requires urgent public disclosure, we may make that distinction at our discretion and publish immediately. There's a good faith element to this and not everything is black and white, but we still believe in full disclosure at our core.

Please read our Submission Process overview here.

How entries are added

There is a methodology to how certain entries are added to the archive. We try to provide as much information possible in the process of addition.

News headlines

Our headlines are direct links to the source. We do not spy on your clicks. We do not try to rewrite the work of other parties. We give you the direct source and provide tagging to find similar articles of relevance.

Files

All additions to the archive are added with as much telemetry as we have available to us. We add relevant tagging, homepages, authors, related CVEs, descriptions, and titles.

Titles for tools have a syntax of TOOL_NAME VERSION_NUMBER. If the tool is a simple one off script, it may have a simpler name like SOFTWARE_AUDITOR. Titles for exploits follow the syntax of SOFTWARE_AFFECTED VERSION(S)_AFFECTED FLAW_TYPE. If we do not have a version available, it may be omitted. Titles for advisories may follow the syntax of COMPANY_NAME - ADVISORY_NAME or have a description that follows suit with the exploit title methodology. Whitepaper titles follow the name of the paper. Articles are usually verbatim with the target link.

File entries will have a relevant homepage, author details, tagging, CVEs, noted changes for the release, and more if it is available to us. Please note that most tools are distributed as source code to ensure that you have the ability to analyze what you are going to execute. If a binary is provided, it will usually be noted in the description. We post source code so that paranoid security engineers, like us, can review what the tool does before trusting it on their systems. We also strongly encourage open source software because we all benefit from sharing.

---

A note from the editor

Disclosure Logistics

We have seen some poor behavior from corporations over the years as they ship horrifically vulnerable software. They tend to threaten researchers who let them know about an issue in good faith, sometimes getting them charged by law enforcement for "hacking". They may not even address a vulnerability for years, if ever. Other corporations, trying to be more civil, have bug bounties to reward researchers for their findings. After all, that reward is still a super cheap cost for what a security assessment might have cost to find the same issue. Bug bounties have become more prevalent and we think that's great in some regards, but we have yet to see one that requires their customers to do the right thing. The right thing is to not only patch by X realistic timeframe, but to also release any and all details to the general public. The release of details is critical.

Technically competent parties, without ulterior motives, will tell you the same. If we know about an issue that affects our company and know there isn't a patch out yet, we may need to mitigate the issue in a different manner to protect the network. We may need an exploit to fully understand how the vulnerability is leveraged and how to design a mitigation. When distilled down, it's that simple. You cannot fix a problem you do not understand. Any consumer of any technology should have a right to know they are at risk. Sharing information benefits everyone. The longer a technology firm drags their feet on addressing an issue, the more it hurts the consumer. It is as simple as that.

We have seen firms take months to release patches because too frequent of patch cycles can cause bad optics, in their mind, with their customers. This left their customers vulnerable for quite some time. Would that be acceptable in any other situation?

A good comparison in real life is a doctor’s visit to get some health checks. You get some tests performed and never receive any feedback. The next year you come in for a sprained wrist and the doctor says "you have a sprained wrist and from last year's CT scan it seems you have stage 4 cancer". By now the cancer has spread. Recovery is most likely not possible. Now apply that same logic to a vulnerability in your network or device that lets hackers in. How long have they been in and how compromised are you?

Packet Storm's viewpoint has put us at odds with some parties in the security industry pushing the "responsible disclosure" ideology. There is a belief that you should notify vendors first when an issue is discovered. That you should wait until they provide a patch and work with them on a public disclosure date for the safety of their user base. However, that mentality does the opposite, and most know it.

Some researchers follow this methodology to mitigate legal threats while others stand on soap boxes and demand this is the only way to mitigate mass hacking from script kiddies! However, it doesn't matter if 1 or 10,000 hackers have an exploit. The reality is that automation is a key element when people break into systems. A single hacker can root tens of thousands of systems. We have seen it. Arrogance, ego, profit, and/or naivety is what usually drives the responsible disclosure angle.

With the recent public discourse around Mythos-discovered vulnerabilities, our first thought was "this is great, all of these issues are going to finally get addressed". The information should have been made public immediately, in our stance, because many of those zero days were already discovered and being leveraged in a malicious context whether or not you want to believe it. Now knowing that they have surfaced and can be addressed is a windfall for the vendors, but to pretend that they’ve never been discovered beforehand is quite naive.

An explanation in a story

When "responsible disclosure" discussions were ramping up a couple of decades ago, a well-respected researcher put out an advisory noting an overflow in a popular source repository software. Packet Storm saw the advisory and posted it. The researcher was reticent to provide any exploitation details, worried that he would cause the next big problem on the internet. He worked with the vendor and awaited for them to release a patch. But that concern was not based in reality. It was based in self preservation and ignorance. A) He didn't want to be the guy who caused the next big problem and B) he believed he was the only one who knew about it. Just because you discovered a vulnerability does NOT mean you are the first to do so.

Within an hour after posting the advisory, an email showed up in our spool with a note: "Well, I guess my zero days are burned," or something to that effect.

Inside the exploits read:

We already owned everyone and everything with these exploits years ago, and in fact we've all had them sitting on the shelf gathering dust due to lack of new targets.

Attached were two remote root exploits for two different unix architectures, exploiting the same vulnerability noted in the earlier advisory. They were quite well written. In a twist, we noticed the mail came from root at the software maker's domain. We saw in the email headers that it came from the repository software servers themselves. We reached out to the compromised company that produced the vulnerable software and explained the implications, as they were a huge entity. They were the standard used at the time. Not only were their systems compromised, but it was unknown how long their software may have been completely backdoored. This was a "the world is actually on fire and source code may be backdoored everywhere for the foreseeable future" sort of situation. When you take time to connect the dots, this sort of hack has immense implications. Always take time to connect the dots.

Any seasoned hacker will tell you that attackers don't just get root on a system and say, "neat. I got in." No, they ensure persistence through various rootkits and even legitimate access flows. The more subtle and easy it is to miss in forensics, the better. They sniff any traffic possible and exfiltrate every bit of data they can. They backdoor any distributed software itself to extend their foothold to customers. They branch out and compromise more and more of your network. They may pull other attackers in to help. Before you know it, your entire network could be overrun by crime gangs that you'll never 100% remove. This is reality. We have seen it in practice for over three decades.

Years later, I crossed paths with the engineer from the compromised company who answered the phone and handled the incident. It was not lost on me that he was interviewing for a position that included incident response responsibilities. The valley can be a very small place. We were both in different jobs at that point and when we realized who each other were, having only spoken over the phone prior, the conversation shifted. What a perfect opportunity to see how this individual's mind worked the investigation. I wanted to understand how he remediated all the concerns we brought to light. Unfortunately, his responses were terrifying. They just patched the software vulnerability and reinstalled their distribution server. They never looked for any backdoors or beyond the primary system that was compromised. It would have been “too much work”. Once again, I found myself staring out a window, catatonic, after our discussion. This was over twenty years ago.

You can try to dress up your disclosure stance by putting the word "responsible" in the name, but to us it's horribly irresponsible.

But why does the archive need live exploits?

If you're asking this question, you probably don't work in a very technical capacity in the security industry. That's okay — we will explain. Understanding the exact and full details of how a vulnerability operates is paramount to finding the proper solution, and exploits provide that level of detail. If a vendor fails to provide a patch, you may have to create one yourself and test it. In order to test your mitigation, you need to know the vector of attack as is provided in an exploit. Without exploitation details, it can be much harder, if not impossible, to do your job. When all you know is that a vulnerability results in remote code execution, but you do not have enough details to create your own mitigations, you can get pushed to a hard decision.

One such instance we witnessed was a large antivirus firm losing millions of future dollars from a subscription customer because they refused to patch a vulnerability that could have allowed for code execution. They felt they were too big to fail and there was no way they could be easily replaced — not by a company with hundreds of thousands of employees that was massive in scale. However, leaving the entire network at risk was a non-starter for the customer. The antivirus firm lost all future revenue due to arrogance and negligence. It was a failure that is probably used in their internal business training courses today.

Isn't Packet Storm just a hacker site?

When this term is spoken, it usually has a negative connotation. The term "hacker" has been manipulated for years with sensational media stories and movies portraying hackers as more dangerous than anyone on Earth. The reality is that hackers are the reason we have any security whatsoever in any tech space. The most qualified security professionals you will ever meet usually spent time in the gray areas of the hacker world. It does not make them bad people, nor attackers in any way — it makes them people who pay attention. Paying attention and learning is critical to evolving.

As we learn how to manipulate and change the behavior of something meant to operate in a different capacity, we identify mistakes and can change behavior in the future. From our perspective, anyone who isn't aspiring to be a hacker of some sort in this day and age is going to be left behind as technology continues to progress.

"Our only security is our ability to change." - John Lilly

Big tech makes it worse

We have seen a multitude of poor behaviors in big tech, such as "secret" mailing lists where vulnerabilities are disclosed between a set group of security types working to secure their companies from a given vulnerability before the details go public. By having these exclusive channels with faux embargoes on sharing, many turn a blind eye to their own behavior as long as they feel important enough to be included. This comes back to ego and arrogance again, and it harms the greater good.

The handful of large tech companies should not be the only ones with this information, and it demonstrates their monopolistic behavior in real time. As long as the entire internet is operating under the same set of technologies, the information should be shared with everyone. Everyone needs to protect their domain.

Fortunately, others think like us

Over the years, Packet Storm has received support from places we never expected, and we cannot thank everyone enough for getting involved. There are quite a few people in important places who quietly worked in the background to help keep us moving forward, and that is by design. Packet Storm has always operated in a fashion where no one is involved for name recognition, but rather a constant focus on the mandate. And that's what has attracted much of the help we have received over the years. We are thankful to be a part of one of the most interesting and necessary communities in modern society — the security community. Keep hacking!