Insights

Cybersecurity digerati spends an inordinate amount of time focusing on the concept of “biggest” when it comes to cybersecurity threats. While there is some merit to such quantification, the concept itself can be difficult to generalize, since every organization has some set of unique characteristics that cause each of them to have fairly unique threat profiles, risk tolerances, and exposures. 

We can, however, break down some of the broader themes from Black Hat and DEF CON 2023 and pull out some recurring themes across each that would cause some consternation for CISOs, CIOs, CEOs, and board members (since many of them are now on the hook when cyber things go south).

Recurring - Theme 1: Insecure By Default CPUs

Meltdown, Spectre, and L1 Terminal Fault (Foreshadow) may be behind us, but modern processor architectures seem to be in a permanent state of vulnerability. Downfall is yet another one in this line of low-level flaws that require significant effort to mitigate, as said mitigations usually require some downtime and also some inherent risk in the patch processes themselves. 

Fixing these vulnerabilities also may cause significant performance degradation, which may force organizations to incur extra spend to meet pre-projected capacity requirements.

C-suite folks are left with a gnarly, tangled risk assessment process that has to consider the likelihood and frequency of projected attacks and also the potential impact on various compliance requirements if they choose not to patch/mitigate.

This is a major distraction from delivering on core business functions, and we’re likely to see more of these types of vulnerabilities in the future, especially with the scramble to acquire GPUs. CVE-2022-31606, CVE-2021-1074, and CVE-2021-1118 are already known vulnerabilities in GPUs, and the rush to meet AI headfirst may see a parallel set of headaches on the horizon in any systems that are performing advanced ML/AI processing.

Recurring - Theme 2: Trouble In The Cloud

It’s no secret that an ever-increasing number of organizations are moving some or many workflows to cloud environments, joining the ranks who have blazed the trail before them. There was supposed to be some inherent level of trust in cloud providers to take security seriously, so all an organization had to do was ensure they didn’t mess up their configs or expose vulnerable services. Sadly, that has not been the case for some time now.

The specifics of what were presented at or before Hacker Summer Camp in this space really aren’t as important as the theme itself: you can no longer even remotely have any baseline level of assurance that the cloud environments you are adopting are taking security measures seriously.

This puts C-suite folks in a precarious position. While some cloud plans end up going over budget, there are many cloud use cases that do help organizations save time, money, and people resources. Yet, when you are put at serious risk due to negligence on the part of a cloud provider you have the potential of incurring significant costs for triage, incident response, and potentially data breach penalties.

2023 has made it pretty clear that “In Cloud, We Trust” is unlikely to ever be a motto again (if it ever was). Organizations now have extra complexity both up-front (as they bake in extra security measures and potential incident costs into new endeavors) and also as they handle the distraction of retrofitting a more defensive security posture onto systems that were likely more secure when they were hosted back in the “owned data center” days.

Recurring - Theme 3: AI Insecurity

There has been enough discussion about “AI insecurity” ever since just around this time last year, so I can keep this relatively brief.

The large language/generative models (LLM/GPTs) we seem to be stuck working with were all trained with no thought for safety — either in the results one gets when using them, or for how easy it is to cause them to reveal information they shouldn’t.

They also come with an equivalent to the “cloud” problem mentioned above, since most organizations lack the skill and resources necessary to bring AI fully in-house. 

This is a big topic of discussion when I talk to CISOs in my lectures at CMU. The AI gold rush is causing organizations to incur significant, real risk, and there are almost no tools, processes, guides, or bulk expertise to help teams figure out ways to keep their data, systems, and humans safe from AI exposures.

This is yet one more distraction, and focus grabber that makes it very difficult to just get “normal” cybersecurity practices done. Unless the bottom falls out of generative AI as it has with the web3/crypto fad that came before it, the C-suite will have to dedicate what little time and resources they have to corralling and shaping AI use across the organization.

Missing - Theme 4: The Vulns Start Coming And They Don’t Stop Coming

There were many talks about vulnerabilities in general at both Hacker Summer Camp and RSA this year. But, I don’t think any talk made the brutal reality of what it is like to perform the thankless task of vulnerability management within even a moderately sized organization.

That calendar view has a colored square every time there’s been a CISA Known Exploited Vulnerability release since CISA began curating their catalog. Apart from the regular mega “Patch Tuesday” organizations have to deal with, they also have to contend with nigh immediate response to each new update, even if that’s only a triage event. There is little time in-between updates, and very common technologies/products make their way to the list on-the-regular.

Six weeks before Black Hat, there was at least one, major vulnerability in a core component of most enterprise IT stacks every week, with rapid and devastating malicious attacks following close behind each release.

This is an untenable situation for most organizations, even “resource rich” ones.

Hundreds (one estimate, today, said “thousands”) of organizations have been devastatingly hurt by MOVEit exploits, Citrix admins likely cannot sleep at night anymore, and even security teams have had to face an onslaught of patches for technology they’re supposed to be using to keep their organizations safe.

We rarely talk about this because it’s a hard problem to solve and causes real, lasting damage. It’s far “cooler” to talk about that “EPIC vulnerability” some clever researcher found in isolation. But, when they’re disclosed back-to-back, as a few security vendors did before Black Hat, it quickly moves from “cool” to a cold, hard annoyance.

More work needs to be done at and outside Summer Camp to help figure out ways to enable defenders to keep their own shops safe without dealing with the IT equivalent of a weekly hurricane sweeping across their asset landscapes.

Getting Off The Hamster Wheel Of Pain

“Recurring theme” is just a fancy way of saying we’re repeating the same negative patterns of the past and making little to no headway, or — to put it another way — we’re in a “two steps forward; three steps back” operational model as we work to overcome each new challenge.

However, all is not doom and gloom, and there are ways to strive for more positive outcomes. 

Fundamentally, organizations must take a proactive and pragmatic approach to enhance their security posture.

For CPU vulnerabilities, investigate tools that can help detect and mitigate risks, and have a plan to rapidly patch and potentially downgrade performance if needed. Cloud providers should be evaluated closely, with redundancy and controls to limit damage from potential exposure. AI and generative models require robust testing, monitoring, and human oversight to prevent harmful outcomes.

Most crucially, vulnerability management programs require sufficient staffing, automation, and executive buy-in. Prioritization aligned to business risk can help focus limited resources. Communication and collaboration with vendors, regulators, and peer organizations could also move the needle on systemic issues.

While hacker conventions highlight scary scenarios, security leaders who take balanced action can still fulfill their mission to protect their organizations. With vision, realism, and tenacity, progress is possible even in the face of ongoing challenges.

Remember, GreyNoise has your back when it comes to vulnerability intelligence. We’re here to help you keep up with the latest CVEs, assist you in triaging a barrage of IoC’s, or providing you with the essential details necessary to make sense of the ever-changing vulnerability landscape.

‍

‍

The Managed Security Service Provider (MSSP) and Managed Detection and Response (MDR) markets continue to face significant challenges in handling a large number of security alerts and vulnerabilities across multiple client environments. While this task is made even more difficult by the shortage of cybersecurity professionals in our industry, it is critical to note that the ideal solution isn’t adding more hands on deck.  It's leveraging innovation and technology that amplifies the capabilities of existing teams. 

MSSPs & MDRs require solutions that enable them to provide top-notch services to their clients while balancing already thin profit margins, all while ensuring they prevent analyst burnout. They need ways to quickly identify and respond to threats with confidence, without compromising on efficiency or service quality.

At GreyNoise, we understand the importance of every second in your margin-driven business. That's why we save you time, resources, and money – all while helping you expand your customer base. We gather, analyze, and categorize data on IPs that mass scan the internet and saturate security tools with noise. This allows analysts to spend less time on irrelevant or harmless activity and more time on targeted and emerging threats.

Here are just a few of the ways GreyNoise is helping our MSSP & MDR customers:

REDUCE COSTS

• Trigger 25% fewer alerts across your SOC.
• Avoid hiring additional personnel to manage alert overload.
• Focus analyst time on triaging real threats.

IMPROVE SCALABILITY

• Reduce customer escalations & missed threats.
• Expand your customer base without expanding headcount.
• Grow without compromising service, accuracy, or speed.

BEAT THE ADVERSARY

• Empower your team with rich IP context & explainability.
• Know about malicious IPs days ahead of other vendors.
• Gain real-time visibility on emerging vulnerabilities.

GreyNoise scales in a way your analysts can’t. But don’t just hear it from us – see how leading MSSP Hurricane Labs is reducing costs while growing their customer base with GreyNoise.

"Any single analyst can handle, say, 20 alerts per day. But a product like GreyNoise can triage alerts for every one of our customers. So as we add more customers, GreyNoise scales in a way a person can’t.”

-Director of Managed Services, Hurricane Labs 

Want to learn more about how GreyNoise can help your MSSP & MDR?  Schedule a demo with a GreyNoise expert.

‍

During our latest webinar Proactive Defense Made Easy: Leveraging GreyNoise in Your SOAR Playbooks, we discussed some everyday use cases using GreyNoise with other SOAR platforms. The main goal of using GreyNoise with other SOAR platforms is to quickly identify either opportunistic attacks, get better insight into how infrastructure is being used, as well as enriching alerts using RIOT data to IP's associated with common business services.

Using GreyNoise to identify opportunistic scanning provides context to decisions in a SOAR playbook to either decide to investigate further or more quickly move to block IP's. Adding the checks into an investigation playbook provides data on scan activity and any vulnerabilities observed as being exploited.

RIOT data also provides quick data for an investigation. Many services integrated into an investigation playbook will provide details for when something is malicious but often don't provide details on known or known good services. Everyone wants the confidence to take action with their automation but may not have the insight needed. Additionally, no one wants to be wrong about this decision. RIOT adds this information to a playbook to assist with decision-making.

GreyNoise can be used in common SOAR use cases to provide better context to phishing playbooks and investigations and have more confidence to block IP's. The power of GreyNoise, alongside other intelligence tools like Recorded Future, VirusTotal, Tines, and Splunk, is nothing short of astonishing(see our full list of integrations). I hope the insights shared during the webinar inspired you to explore these tools further and optimize your cybersecurity investigations. Sign in/up for GreyNoise to explore our data for free.

Watch the full webinar

‍

In today's world, where networks generate an overwhelming amount of data, security analysts often find themselves struggling to separate the real threats from the noise. Their days are spent in a constant reactive mode, leaving little room for proactive measures due to limited time and resources. In this blog post, we'll delve into how GreyNoise empowers security analysts and transforms their daily work by cutting through the noise and providing invaluable insights.

So, what exactly is GreyNoise?

GreyNoise is a powerful threat intelligence platform designed to assist security analysts in identifying noise and minimizing false positives. By meticulously collecting and analyzing internet-wide scan and attack data, GreyNoise equips security teams with contextual information about the threats they encounter. With its ability to filter out noise and shed light on the sources of attacks, GreyNoise empowers security analysts to focus their efforts on genuine threats.

How we can help

1. Maximizing SOC Efficiency: Banishing False Positives

Security Operation Centers (SOCs) are often inundated with an overwhelming barrage of security alerts. However, it's disheartening to discover that a significant portion of these alerts, often exceeding 50%, are nothing more than false positives or irrelevant internet noise. One exasperated GreyNoise customer even lamented, "Stop chasing ghosts!" (this is why you will see our little “ghostie” icon many places on our website and in our product) GreyNoise comes to the rescue by enabling SOC teams to filter out known benign and noisy alerts originating from SIEM and SOAR systems. This empowers analysts to laser-focus on targeted and malicious activities that truly demand attention. Learn More >>

2. Enhancing Threat Intelligence: The Power of Context

GreyNoise takes threat intelligence to new heights by providing security analysts with valuable context surrounding the sources of attacks. Through thorough analysis of internet-wide scan and attack data, GreyNoise identifies patterns and offers insights into the tactics, techniques, and procedures (TTPs) employed by attackers. Armed with this knowledge, security analysts gain a deeper understanding of the threats they face, enabling them to devise more effective strategies to mitigate risks and safeguard their organizations. Learn More >>

3. Defending Against Mass exploitation Attacks: Staying One Step Ahead

GreyNoise provides an early warning system for vulnerabilities being actively exploited in the wild, plus dynamic IP blocklists that security teams can use during their window of exposure. Now you can swiftly identify trending internet attacks focused on specific vulnerabilities and CVEs, efficiently triage alerts based on malicious, benign, or targeted IP classifications, and take proactive measures to block and hunt down IP addresses opportunistically exploiting a particular vulnerability. By leveraging these comprehensive features, security teams gain an edge in staying ahead of threats and bolstering their defenses against mass exploitation attacks. Learn More >>

Conclusion

Security analysts grapple with numerous challenges in their day-to-day work, including the overwhelming volume of network data and the complexity of evolving threats. However, GreyNoise emerges as a formidable ally, providing context about attack sources, reducing false positives, and bolstering incident response capabilities. By harnessing the power of GreyNoise, security analysts can direct their attention to genuine threats and ensure their organizations remain resilient against cyber threats.

Take the first step and explore our data for free to experience the transformative power of GreyNoise firsthand. 

‍

The Situation

Threat hunters spend a significant portion of their time searching through security logs looking for specific Indicators of Compromise (IoCs) or patterns of activity/behavior that indicate compromise. This work comes with some specific challenges: 

• Too Many Tools, Too Much (Nonsense) Data: Oftentimes, threat hunters end up with log files or results pages showing long lists of suspicious events (including related IP addresses), and it can take many hours to work through this information to filter and identify malicious activity. 
• Time Spent Clustering: Identifying infrastructure used by adversaries is a time consuming process.‍
• Building Early (but reliable) Detections: Detections developed to identify malicious activity can generate false positives or get outdated quickly if they are based on non-current data.

Techniques to Improve the situation

To further enhance threat hunting and address some of these pain points, organizations can use tools like GreyNoise in conjunction with a SIEM or SOAR platform to quickly identify potential threats and investigate them further and get more out of their existing tools and filter through data sources faster. By understanding how infrastructure is being used, vulnerabilities being leveraged, and patterns of scans, threat hunters can gain valuable context on how adversaries operate and improve their response to threats.

Recently, we held a webinar on this topic, where we discussed how organizations are using specific techniques in their day-to-day operations. To gain perspective on how you can streamline your threat hunting process, sign up for the webinar and download it today to learn: 

• How to use GreyNoise features and SOAR playbooks to hunt, detect, and defend.
• The ins and outs of analyzing logs to identify potential DDoS attacks and how to respond to them effectively.
• Tips and tricks for incorporating vulnerability intelligence into your threat intel reports, which can help you stay ahead of emerging threats.

As a Product Manager at GreyNoise, I’m constantly learning about how our users think about internet noise and accordingly search our data with the GreyNoise Query Language (GNQL). It might surprise you (or not) that we see some pretty random searches.

As evidenced by our 2000s style word cloud, users have been searching anything from “log4shell” to “lockbit” to “mcdonalds.” While GreyNoise search is not a threat actor Google, we do have a lot of data on interesting threats. Let me clear up our search bar for those of us who want to improve our ninja search skills.

What can you search for in GreyNoise?

The answer is anything, which is why you should use GNQL searches!

When you throw a word into the GreyNoise Viz search bar, we treat it like a free text search, where we search all of our data for that term - so this means if you search “banana,” we will return the IP addresses that have scanned for the “/banana/” directory. But we might also return IPs with “banana” in their user agent.

The GNQL way of guaranteeing you only get IPs with “banana” in the HTTP web paths is to utilize the raw_data.web.paths field selector. The search for our banana path would look like raw_data.web.paths:"/banana/"

More fun with field selectors in GNQL is in our Cheat Sheet.

If you’re looking for an exceptional user agent or organization, we also have field selectors: raw_data.web.useragents and metadata.organization respectively.

For the searches that are word-based but land outside web paths, user agents, and organizations, we have a few other categories they might fall into - Actors, Tools, Botnets, and Techniques. For these, I recommend searching our tags. This is as easy as going to the tags page and utilizing the tag search bar, where we can return all our tags containing your search term.

As for threat groups - at this time, GreyNoise does not dabble in attribution to threat groups. If you’re looking for a particular group, we recommend identifying IoCs that the groups may use if you’re trying to track them down. We have found initial reconnaissance IPs in reports from other research groups lurking in our data and have those web paths that may indicate compromise by C2/botnet activity.

I hope these tips helped level up your GreyNoise search skills to help you find what you’re looking for even faster. Create deep dives into something haunting you using our Cheat Sheet, and stay tuned for more internet noise search tips soon!

‍

‍

Spoiler Alert: It’s a lot…

SOC teams have struggled with false positive alerts since, well, the beginning of security centers. There are a lot of studies (by security vendors) on how much time SOC analysts spend on false positive alerts. Unfortunately, we are not IPO rich (yet) - so we didn’t conduct our own study - but we did take the average from a few (1, 2, 3) reports. According to our sources, a single analyst wastes an average of 8.4 hours per week triaging false positive alerts.* 

GreyNoise can help SOC teams reduce false positives by providing context to the alerts on internet-wide scanners, crawlers, and other suspicious activity that may trigger false alarms. How many times have you got an alert that turns out to be [insert security company] just scanning the internet?

‍

By integrating GreyNoise into your alerting workflow, your team can eliminate background noise and focus on the most actionable and relevant alerts.

So what can you do with ~8+ hours of your life back each week?

1. Make this delicious Lemon cheesecake recipe
2. Knit this Lace shawl
3. Hike the Inca Trail of Machu Picchu
4. Build a coffee table
5. Run a 50m (ultra?)marathon 
6. Go Scuba diving, twice
7. Tour the entire country of Monaco
8. Listen to the longest continuous orchestral piece in history 
9. Watch the first three of the Fast and Furious movies
10. Give yourself an NFC manicure 

By using GreyNoise to filter out benign internet scanners, SOC teams can improve decision-making, reduce alert fatigue, and enable teams to focus their time and resources on genuine threats. Start exploring our data today.

*Yes, we know that the actual time spent varies based on the size of the security team and organization.

‍

We recently built out a new Premium Feed for Anomali ThreatStream. Anomali customers can now pull in all malicious IPs GreyNoise has seen hitting our sensors in the past 24 hours, on a daily basis. 

While most feeds in Anomali are used to build lists of observables that will trigger alerts or investigations within their other security tools, GreyNoise is not your typical threat feed and should be treated differently. In this post, we’ll walk through how Anomali users should leverage the GreyNoise feed, how you can access a trial, and a couple other loose ends.

GreyNoise Malicious Feed in Anomali

Observables that show up in the GreyNoise Malicious Threat Feed in Anomali all have three things in common: 

1. They are part of our Noise data set which means they have been seen scanning the internet in the past 24 hours BY GreyNoise (we are the first-hand collector of our data)
2. In the past 30 days, they’ve done something GreyNoise determined to have malicious intent when interacting with our sensor network
3. They are NOT a benign actor with a legitimate reason for scanning the internet that may look suspicious, but ultimately would be a waste of time or could have negative consequences if blocked.

Because of these, customers trust that GreyNoise Malicious Feed observables are associated with an IP that has been seen blasting large swaths of the internet, and likely not indicative of a targeted attack worth an analyst’s time to review. 

GreyNoise’s Malicious Feed in Anomali is best used as a feed for opportunistic attack activity that should be automatically blocked. Our data is highly reliable so many of our customers trust our data to leverage in automated actions, like blocking, to save their analysts’ time. Our malicious feed should NOT add to an analysts triage queue. 

Try it out

In order to try out the GreyNoise Malicious Feed in Anomali, you need a GreyNoise account with an active Enterprise trial. Start by Signing Up Here then clicking on the Activate Trial button on the GreyNoise Account page. Once you have the trial enabled, grab your GreyNoise API key, and head over to the Anomali Marketplace.

‍

‍

In the Anomali Marketplace, find the Premium Feed for GreyNoise, then click Get Access and drop in your API key. This will provide you with 14 days of trial access to the feed.

If after the trial you’d like to make it a permanent feature in your Anomali instance, you can review our pricing page and reach out to the sales team with any questions. The GreyNoise Malicious Feed can be an add on to any of our standard packages!

A Complement to other Feeds in Anomali

While we’re on the topic, we’d be remiss to not mention the original use case for GreyNoise in Anomali. For observables coming from other sources within Anomali, we provide additional context through enrichment that other services don’t. If you're triaging an event and using Anomali to understand the details of an observable, the GreyNoise Enrichment for Anomali provides you with all the details you need to understand if the IP has been observed performing internet-wide scanning and what it has been scanning for. It will also highlight for you if the IP belongs to a common business service from our RIOT data set, in which instance blocking that IP may break something for your users.
 

Our Anomali Enrichment feature also recently got an upgrade, with IP Similarity and IP Timeline now available if included in your GreyNoise Subscription. These are great tools for folks looking to for a granular view of the scanning activity observed by GreyNoise for an observable or to identify other scanning IPs that may be leveraging similar scan and attack tactics.

‍

‍

GreyNoise is a powerful cybersecurity solution that provides valuable context on internet-wide scan and attack data. By collecting and analyzing this data, we help organizations distinguish between targeted attacks and background noise, reducing false positives and improving security operations efficiency and overall security outcomes for every organization that uses both our Visualizer or API. Today, we'll explore the GreyNoise integrations universe, discuss how these extensions can benefit every category of security tool and service, plus explain why both vendor flexibility and community support is essential. 

How Can All Cyber Tools/Solutions Benefit from GreyNoise API Integrations?

Cyber tools and solutions of every kind can greatly benefit from integrating with the GreyNoise API, even at the community tier. Here are a few ways that these tools can leverage GreyNoise data:

1. Enrich Security Events: By integrating the GreyNoise API into security monitoring tools, users can gain additional context about security events, helping them prioritize threats and respond more effectively.
2. Augment commercial and OSINT Data: Commercial and open-source intelligence (OSINT) tools can benefit from GreyNoise data by providing users with additional insights into IP addresses and scanning activities, ultimately improving the quality of their intelligence.
3. Enhance Vulnerability Management: By incorporating GreyNoise data into vulnerability management tools, users can better understand the risk associated with specific vulnerabilities and make more informed decisions about mitigation strategies.
4. Optimize Incident Response: GreyNoise API integration with incident response tools can help streamline the investigation process by providing valuable context on potentially malicious activities, enabling faster and more accurate response efforts.

The GreyNoise Integrations Universe

The GreyNoise integrations universe is vast and designed to support a variety of security tools and platforms. This includes Security Information and Event Management (SIEM), Extended Detection and Response (XDR), Security Orchestration, Automation, and Response (SOAR), Threat Intelligence Platforms (TIP), and Analyst Tools/Open-Source Intelligence (OSINT). You can see just how vast it is for yourself!  By integrating GreyNoise into each of these solution areas, organizations can enrich their security alerts, enhance visibility, streamline operations, and make far more informed decisions.

The Importance of Vendor Flexibility

Vendor flexibility is crucial in the cybersecurity landscape. By supporting a wide range of security tools and platforms, GreyNoise empowers organizations to tailor their security ecosystem to meet their unique needs. According to buzzword-laden analysts and experts alike, adopting an open and flexible approach to security integrations enables organizations to leverage best-of-breed solutions, maximize the value of their existing tools, and enhance overall security posture. What that truly means, though, is that GreyNoise meets you where you are at, regardless of budget cycle. When that three- or five-year contract is up on that SIEM, rest assured that it’s more than likely GreyNoise will work with that fancy new tool you spotted at RSA. GreyNoise's commitment to vendor flexibility ensures seamless integration with your preferred tools, ultimately improving your organization's security capabilities.

Maximize the Benefits of GreyNoise Integrations

Integrating GreyNoise across your entire environment is highly beneficial. By incorporating GreyNoise data into all the acronyms you own — SIEM, XDR, SOAR, TIP, and OSINT — you can enrich your security alerts with valuable context, reduce false positives, improve incident response times, and centralize threat intelligence data. By leveraging GreyNoise's context across your systems and services, you can gain a more comprehensive understanding of your security landscape and make better-informed decisions to protect your organization.

Our API can help you hone in on anomalies, cast a wider net when it comes to identifying and blocking malicious sources, and provide actionable context on today’s “internet weather”.

GreyNoise Community: A Hub for Open-Source Integrations

GreyNoise has a vibrant and thriving community of practitioners, with members that collaborate on developing open-source integrations with GreyNoise. These community-driven integrations enhance the functionality of a plethora of Free and Open-Source Software (FOSS) cyber tools, demonstrating the versatility and value of GreyNoise data.

Members of the GreyNoise Community invest their time and effort into integrating GreyNoise into open-source projects for several reasons:

1. Improved Security Analysis: GreyNoise data adds valuable context to security events, allowing FOSS tools to provide more accurate and actionable insights.
2. Reduced False Positives: By incorporating GreyNoise data, open-source projects can more effectively filter out internet background noise, reducing false positives and helping analysts focus on real threats.
3. Knowledge Sharing and Collaboration: The GreyNoise Community encourages collaboration and knowledge sharing, fostering innovation and driving continuous improvement in open-source cybersecurity tools.
4. Enhanced Threat Intelligence: Integrating GreyNoise into FOSS cyber tools can enrich threat intelligence data, empowering users to make better-informed decisions about potential threats.

If you're developing or using FOSS cyber tools, consider integrating the GreyNoise API to unlock the full potential of your security solutions. Join the GreyNoise Community and collaborate with like-minded individuals to improve the cybersecurity landscape and make the internet a safer place for everyone.

Integrate GreyNoise Today!

Are you ready to harness the power of GreyNoise? Sign up for a free GreyNoise account and start exploring the benefits of GreyNoise integrations. Experience firsthand how GreyNoise data can enhance your security operations and threat intelligence. For organizations looking to unlock the full potential of GreyNoise, navigate to your GreyNoise account section to sign up for a free enterprise trial and begin integrating GreyNoise into your security ecosystem today. Don't miss out on the opportunity to strengthen your organization's defenses with the power of GreyNoise.

‍

If you’re looking for an extremely wholesome conference to attend, look no further than PancakesCon. This conference requires speakers to talk about 2 things: (1) a brief talk about any cybersecurity topic and (2) a brief talk about something which is not IT-related. As you might imagine, this leads to some great talks! Some of our favorites from this year included:

Collaboration Required: Threat Intelligence Sharing & Coop Board Games (Grace Chi)

Grace led us through why sharing in CTI matters (spoiler alert: it's how we all win) and some of the best coop games (Spirit Island, anyone?!) around to play with family and friends.

‍Playing with Exploits in Metasploit & Playing with Ideas via Clowning (Tina Coleman)

Extremely talented performer Tina live-demoed Metasploit shenanigans (bless the demo gods) and shared her experience as a semi-professional Clown!‍‍

‍Dry Cup: A Primer on Cybersecurity in China (and also Baijiu) (Jonathan Reiter).

‍Jonathan gave an incredible and nuanced background on what cybersecurity looks like in China (with some Mandarin to boot). We also got educated on the customs of Baiju, a Chinese fermented grain alcohol best shared with friends. 

We were also lucky enough to talk a little bit about our hobbies and cyber investigations.

‍OSINT & Oreos: Using OSINT to uncover a network of “House Hunters” (while trying to make homemade oreos)

3 years ago on a Sunday afternoon, I was baking when I got a call from an out-of-state number inquiring to buy a house I owned. Except, I don't own any house. Since then, I have received dozens of calls inquiring about the property and I have always wondered - why me? Who is the owner? Why do people want this house so badly? I got to explore this and more, all while sharing my best tips for weekend baking with Oreos. (or uh generic chocolate wafer cookies). (Why Oreos? It rhymed!) 

Dio9sys: Fancy Nails and Fancy Rails: how to make “smart” NFC fingernails and the Trans Travel Guide to Amtrak

Brianna has a keen eye for fashion (and hardware) and has combined this into the ultimate manicure - “smart” NFC nails. Bri took nail “tip taps” to a whole new level with a true DIY demo. Beyond that, we got a firsthand fan-girl account of the American rail system - the true way to get your fill of adventure in a safe and comfortable environment!

‍

A major thank you to Lesley Carhart, and the entire PancakesCon organizing committee & volunteers - you made the internet feel a little cozier this weekend! 

Whether you’re working with netflow data collected from your own devices, flow logs from a cloud provider, or purchasing data from netflow providers, you may find it challenging to get immediate value out of it. Not only is there a vast amount of data to hunt through, but it can be challenging to fully understand what is happening based on netflow logs alone. While there are plenty of benefits to collecting and analyzing flow data, these challenges can make it difficult to use the data day-to-day to support investigations. 

In order to start using netflow effectively in an investigation, it’s important to have a good understanding of the network and an established baseline of activity. This makes it easier to distinguish between normal traffic on the network and anomalous traffic that should trigger alerts to your team. Beyond defining these baselines, netflow data often needs to be correlated with additional sources such as alerts from the firewall and threat intelligence data to better understand particular flows and further establish patterns and relationships in the connections.

Even with these baselines defined and alerts being created using correlated data, oftentimes users still need to hunt though a massive amount of flow data to identify malicious activity that might have been missed. Outside of looking at deviations from a baseline it can be challenging to determine where to start investigating. 

This is where GreyNoise can help! Filtering opportunistic and mass scan activity with data gathered from GreyNoise’s sensor network fast-forwards the process, allowing analysts and threat hunters to identify  suspicious activity and find targeted threats that might have been missed by other detections . GreyNoise also provides information on infrastructure used by common business services, which can be used to filter egress netflow traffic and hunt for malicious activity leaving the network.

Taking this one step further, let’s look at  organizations purchasing commercial netflow data from different sources. Oftentimes these groups combine this data with internet scanning services like Censys or Shodan in order to identify C2 beacons. While taking a proactive approach like this can help identify infrastructure and compromised systems earlier, there is still a lot of data to sift through. Instead, let’s use GreyNoise as a first pass filter to remove IP addresses that are saturating these sources and focus the investigation to find the signal in the noise.

‍

While the volume of data may present a challenge, flow data also does not always contain all of the necessary information needed to act on. Oftentimes this data needs to be correlated with other sources of data to have a true understanding of the activity observed. Using VPC flow logs as an example, instead of just filtering out the noise, users may also want to identify malicious IP addresses accessing their assets. In this case, enriching the data with GreyNoise provides insight into how these IPs operate and highlights access attempts that may violate defined policies.

Netflow data provides a solid option for understanding who is doing what on the network but comes with an operational  challenge  based on the volume of traffic and the lack of details in the data. In order to address these challenges:

• Filter the data with GreyNoise to remove flows that teams don’t  need to focus on and speed up investigation times
• Enrich IPs with GreyNoise to  better understand threats and build  detections  to support SOC and IR teams.

If you are interested in learning more about how to operationalize netflow data with GreyNoise, request a demo.

‍

‍

Our friends over at Elastic published a great piece on how to set up Distributed Alerting with Elastic Stack - and gave a shout out to us! As big proponents of SOC efficiency and sleep-filled nights for Incident Response teams, using GreyNoise data in your process with Elastic Stack and Tines can (1) prevent false positive alerts from ever reaching your SOC teams and (2) help provide additional context when you do receive an alert. 

Our sensors are placed around the world to passively capture network traffic and give you details on what IPs are scanning the internet on a daily basis. We then tag the behavior we’re seeing with additional details and deliver that context to our users to help you understand what traffic is benign and what traffic is attempting to exploit everyone (or just you). 

‍

Beyond our Noise dataset as described above, we also provide data on common Internet services (Google DNS, Apple, CDNs, etc.), known as RIOT. 

By adding GreyNoise data (Noise and/or RIOT) into your Distributed Alerting workflow, we can help enrich logs with full context data on IPs seen by our sensors. As our friends at Tines highlighted, “Simply put, if an IP is classified in RIOT and has a trustworthy confidence level, the impact of the alert is very likely to be minimal, and it can be set as a low priority or closed immediately. Suppose the IP has a somewhat trustworthy confidence level. In that case, the priority could be raised, and/or additional risk factors could be added in to arrive at a confident automated determination of the status of the alert before any analyst review.”

GreyNoise has both Elastic and Tines integrations available to our paid users, which we’re happy to demonstrate further. Whether you’re trying to tune your alerting system or digging deeper in an investigation, we hope you check out our data further. 

Start an enterprise Trial today.*

‍

(*Create a free GreyNoise account to begin your enterprise trial. Activation button is on your Account Plan Details page.)

‍

One of the things that I was really excited about when I joined GreyNoise was the amount of data gathered by our sensor network and how it could be used in other ways outside of the traditional SOC efficiency use case. I spend a lot of time working with GreyNoise data, and inevitably, finding some thread to pull at that leads me down a rabbit hole. Our sensors see hosts that are scanning for known CVEs and misconfigurations end everything in between, but with the introduction of IP Similarity, we’re now able to group IPs by how they are operating, providing intelligence on botnets or even infrastructure used by adversaries. 

Prior to this feature, users would have to look through GreyNoise data and extract this manually. Now, using a combination of ports, requests, and fingerprint data the new IP similarity feature does the work for you. In preparation for a meeting the other day, I was looking through some of the ICS tags published on GreyNoise and reading up on the Tridium NiagraAX Fox ICS Scanner, which is always interesting to look at who’s scanning for it, as well as the results on Shodan/Censys since they typically provide details about the building they are located in.

‍

Digging into the results, there were a couple of IPs that stood out immediately, especially the ones that were classified as unknown. If you’re not familiar with GreyNoise, these are IPs that we’ve observed scanning the internet but haven’t seen any malicious activity from. There were a number of IPs that were scanning for ICS tags, and several in particular seemed to be opportunistically scanning for really any kind of SCADA device exposed to the internet. In this case, there is a JA3 fingerprint that we can pivot on, but the hash 19e29534fd49dd27d09234e639c4057e returns over 7,000 results.

That’s still a lot of information to parse through, and we could use a combination of requests and tags, but by using IP similarity and filtering down to a confidence score of 95% or greater, we can quickly find 8 other IPs that have been active in the last month all performing similar reconnaissance. This now gives us a way to start further investigating infrastructure and better understand what these IPs are targeting. 

Coming from the SOAR world, we were always looking for sources that could be used to make better decisions when automating responses or threat hunting. IP similarity now makes it even easier to identify common infrastructure and botnets in order to further hunt based on the data. It also makes it easy to create a blocklist since we know that these IPs have all recently had very similar scan behaviors. 

I’m really excited about the different ways people are going to be using IP similarity and the benefits they will get from this new feature. Try IP Similarity for free with our enterprise trial** or contact us for a demo.

‍

(**Create a free GreyNoise account to begin your enterprise trial. Activation button is on your Account Plan Details page.)

‍

‍

‍

How often do you find yourself asking “is this targeting me or just opportunistically exploiting parts of the internet?” Whether this has happened to you once or happens every single day, you probably spent too much time trying to figure out the answer. At GreyNoise we help our customers answer this question and many more. Here are the top 6 ways we can help threat hunters improve their investigations.

Wildcard and Boolean Searches

The GreyNoise Query Language (GNQL) is well documented, but you often want to query GreyNoise without knowing exactly what you are looking for. Using wildcard searches in conjunction with boolean logic lets you start with a broad search and then begin to remove items that aren’t interesting based on specific conditions. For example, starting with a search for the tag “RDP Alternative Port Crawler'' returns close to 8000 results. Or using the query cve:"CVE-2022-*" shows over 1600 IP addresses observed by GreyNoise.

When starting with a broad search, there can be a lot to unpack in the data, but that’s where the boolean operators can be added in. You can remove things like organizations or countries that you’re not interested in. Alternatively, you can filter out specific fields, including ports or IP’s classified as benign by GreyNoise. Using the RDP Alternative Port Crawler as an example, by removing a few noisy organizations and ports we can end up with some interesting results with a query like this:

tags:"RDP Alternative Port Crawler" NOT classification:benign NOT raw_data.scan.port:3389 NOT (metadata.asn:AS14061 OR metadata.organization:"Linode, LLC") 

‍

Querying by ASN or Organization 

Sometimes, a user might have a particularly active IP address that they are researching, but not seeing any activity from the IP in GreyNoise. Even if there isn’t a match for a specific IP, users can query GreyNoise by ASN or organization. Digging through some web logs there was a particularly interesting IP address looking for exposed cryptominers. Although GreyNoise hadn’t seen this particular IP, querying based on the ASN provided some details on the type of activity observed from this specific organization. Nothing in the results jumps out as particularly malicious other than one host. Still, it can be helpful to understand where the scanning originates from, and how the hosting provider handles complaints, or how common it is to see their services abused. 

Example query: metadata.asn:AS41608

‍

JA3 Hashes

JA3 is essentially a way to fingerprint SSL/TLS connections and the applications associated with them. Using these hashes we can start to better understand how an actor is operating and what tools they are using. As a quick example of using JA3 hashes with GreyNoise, let’s look for IP’s that are using bitsadmin as part of their toolkit. Using this GitHub repo https://github.com/marcusbakker/Miscellaneous/blob/master/ja3_hashes.csv we can start hunting using a few of the hashes in the repo:

2c14bfb3f8a2067fbc88d8345e9f97f3 OR 613e01474d42ebe48ef52dff6a20f079 OR 05af1f5ca1b87cc9cc9b25185115607d OR 8c4a22651d328568ec66382a84fc505f

Searching GreyNoise this way allows us to better understand the tools being used and can be useful for building out additional hosts to start pivoting to and collecting additional indicators for hunting. 

Plus, without JA3 hashes how could we easily identify hosts looking for license.txt files across the internet? 1f24dbdea9cbd448a034e5d87c14168f

‍

‍

Interesting Requests

GreyNoise tags are built to identify the activity observed across sensors, but looking into the raw requests can provide some interesting insights into how these different actors are operating. One easy way to query GreyNoise is with the following:

base64 OR fromcharcode OR powershell OR "sh "

This looks for requests that are attempting to encode a command before executing it or just executing a command as part of an exploit or misconfiguration. This is also a quick way to find C2 servers that might be used as well as IP’s hosting second stage payloads. Typically it appears that most payloads are a variant of Mirai but there have been a number of interesting ones that have been discovered this way.

‍

GreyNoise Command Line

One of the fastest ways to get data from GreyNoise is using the GreyNoise CLI. This allows you to lookup an IP address or query GreyNoise using regular GNQL searches. While this data is easily accessible, combining it with a few other tools makes it easy to write some one liners to pull interesting data from GreyNoise based on tags or recently observed activity. A few of my favorites are below

1. If a tag is written for a vulnerable web application GreyNoise captures and displays the requests observed. As an example, using the tag for CVE-2022-26134 you can extract the first command to be executed, assuming the application is vulnerable. This can provide all kinds of interesting details from commands being run, to files being modified, and even finding second stage payloads being downloaded and executed.‍

• greynoise query 'tags:"Atlassian Confluence Server CVE-2022-26134 OGNL Injection Attempt"' -f json -v | jq ".raw_data.web.paths" | grep "org.apache.commons.io.IOUtils" | awk -F '[()]' '{print $6}' |sed 's@\\@@g' | sort | uniq

2. These two are pretty similar and are designed to find requests or user agents from newly seen hosts across the GreyNoise sensors. A lot of this can be pretty typical paths that are seen but you can also find some interesting new paths that hosts are scanning for and find new tools based on user agents.

• greynoise query 'tags:"Web Crawler" first_seen:7d' -f json | jq '.raw_data.web.paths[]?' | sort | uniq -c | sort -r
• greynoise query 'raw_data.web.useragents:"*" first_seen:1d' -f json | jq '.raw_data.web.useragents[]?' | sort | uniq -c | sort -r

3. The stats option in the CLI provides a nice overview of the GreyNoise data. In this case I also want to look at activity that is not on traditional ports to get an idea of where it is originating from and what tags are associated with the activity. Some interesting modifiers to add are country codes, first/last seen time modifiers, or ASN’s.

• greynoise stats 'NOT classification: benign NOT raw_data.scan.port:80 OR NOT raw_data.scan.port:443 OR NOT raw_data.scan.port:22 OR NOT raw_data.scan.port:23 OR NOT raw_data.scan.port:3389'

Combining GreyNoise and other tools

When looking through the backend of GreyNoise one day I noticed that of the top 50 noisiest IPs looking for RDP exposed to the internet they had covered almost every one of the 65,535 possible open ports. Obviously there is plenty of incentive to find RDP exposed to the internet, but it was staggering to see how thorough the attempts to find it is. 

GreyNoise can answer the question “Is this IP scanning just me or large portions of the internet,” but combining this information with other sources can provide fascinating details about IPs we might be seeing. Of the top 20 noisiest IPs 80% had one of these two banners returned on Shodan:

• OS: Windows 10/Windows Server 2016 OS Build: 10.0.14393 
• OS: Windows 8.1/Windows Server 2012 R2 OS Build: 6.3.9600

What was more interesting to see is that even though both of these versions of Windows have some vulnerabilities associated with them, several of them originated from the same provider. This might mean that they have a default image they deploy that is not being updated.

Whether you’re investigating interesting data in our own network or hunting beyond, we hope these tips are helpful on how to do the most with GreyNoise data. If you’re interested in learning more about our Threat Hunting features, check out our solutions page: Contextualized Threat Hunting with GreyNoise or contact us to get a demo.

‍

UPDATE (2023-01-31): Added link to the QA'd Tag.

You may have noticed an anomalous uptick of PUT requests in the GreyNoise sensors these past couple of days (2023-01-22 → 2023-01-24). For those interested, we’ve put together a quick summary of the details for you to dive into.

The majority of PUT requests occurred from January 15, 2023, to January 26th, 2023. During this time period, 2,927 payloads were observed containing HTTP paths of randomly generated letters and either a “.txt” or “.jsp” file extension. Similarly, the body of the PUT requests contained a randomly generated string as text and another randomly generated string contained within the markdown of a Jakarta Server Page (JSP) comment field. We believe this to be a methodology attempting to insert a unique identifier into the target server to determine potential capabilities of further exploitation; such as the ability to upload arbitrary files, retrieve the contents of the uploaded file, and determine if the JSP page was rendered (indicative of possible remote code execution).

The remaining path counts can be seen here:

The most common being "/api/v2…", a path often found in FortiOS authentication bypass attempts. Check out our blog to learn more about tracking this exploit. We’ve also seen variations of "/FxCodeShell.jsp…", which is indicative of a Tomcat backdoor usage. Each has their respective packet example below:

Inquiring into these paths led to a discovery for us as well! Having been formally unfamiliar with the "/_users/org.couchdb.user:..." path, we did some digging, which led to a new signature for CVE-2017-12635.

This highlights novel ways attackers are attempting to fingerprint exposed services using known vulnerabilities, and is a starting point for hunting for additional malicious activity related to these requests.

If you want to do your own threat hunting, check out GreyNoise Trends (Anomalies). 

Researcher Notes

_{When digging into these anomalies, GreyNoise researchers noticed a pattern of randomly generated JSP checking to see if they can upload, and then access their uploaded files.}

_{The FortiOS authentication bypass used both the "/api/v2" HTTP PATH prefix along with a header of "User-Agent: Node.js"}

_{"FxCodeShell.jsp" is associated with a well-known webshell.}

‍

Researchers at GreyNoise Intelligence have added over 230 tags since January 1, 2022, which include detections for over 160 CVEs. In today’s release of  the GreyNoise Intelligence 2022 "Year of Mass Exploits" retrospective report, we showcase four of 2022's most pernicious and pwnable vulnerabilities. 

Activity around the Log4j remote code execution flaw, which burst on the scene in last 2021, continued apace, and has found its place in daily internet background noise along with a cadre of other “celebrity vulnerabilities”. During the initial exploitation period, every single GreyNoise sensor (over six hundred sensors handle traffic from over five thousand internet IP addresses) fielded Log4j exploit traffic, handling nearly one-million attempts within the first week alone. Attackers continue to hunt for newly exposed, vulnerable nodes, and for nodes that may have accidentally had mitigations or patches removed.

The Atlassian Confluence Object Graph Notation Library (OGNL) injection weakness was an especially rueful one since it gave anyone unauthenticated access to any fathomable query, and Confluence is the knowledge repository of countless organizations. Due to the way this API endpoint handles input, clever attackers used varying techniques to obfuscate exploit payloads like the one below to avoid detection:

At the height of exploitation attempts, the GreyNoise sensor network saw nearly 1,000 unique IP addresses looking for exposed vulnerable nodes. We continue to see a daily average of nearly 20 unique addresses hoping for unpatched Confluence instances.

Apache httpd's path traversal and Remote code execution one-two punch may have entered the ring in 2021, but this contender made our 2022 list due to a steady increase in traversal exploit volume throughout the year (nearly 3x as many attempts as when the vulnerability first emerged on the scene). Apache’s httpd server may not have the top spot anymore, but it is still highly prevalent, and patching of legacy instances tends to be very spotty. 

The F5 Big IP iControl's REST authentication bypass made the cut for the report as it hit the sweet spot in terms of the GreyNoise Celebrity Vulnerability Hype Cycle model (which is detailed in the report): 

‍

Finally, GreyNoise researchers took a hard look at CISA’s Known Exploited Vulnerability (KEV) Catalog releases in 2022 (through late-November):

and followed up on our mid-year assessment of CISA’s overall KEV performance, noting that:

• Keen defenders had to deal with a KEV alert on an almost weekly basis in 2022.
• The aggression against Ukraine added many legacy vulnerabilities and the increased threat of nation-state actors into organization threat models.
• Popular enterprise software, across many versions, made regular appearances, forcing defenders to triage KEV lists against known installed software.

GreyNoise has tags for over 100 CVEs in the 2022 component of the KEV catalog. KEV CVEs without tags are ones where we would not see internet-facing remote exploit attempts (though there are a tiny number of KEV CVEs we're in the process of developing tags for).

Out of these 100+ CVEs, GreyNoise tag creation beat CISA's CVE updates 60% of the time, and we tied these updates 5% of the time. You can now search by CVE and set up GNQL like this one we recently published that covers CISA's published list of the top CVEs most used by Chinese state-sponsored attackers. Defenders can then use the pristine block lists (updated by the hour) to either remove the noise before it has a chance to reach them, or filter out the noise from events and alerts to enable significantly faster defense.

Ready to dig in to the data?

What is an Industrial Control System?

Industrial Control System (ICS) is a term describing systems that monitor and control industrial processes, such as mine site conveyor belts, oil refinery cracking towers, power consumption on electricity grids, or alarms from building information systems. NIST references them as “encompass[ing] several types of control systems, including supervisory control and data acquisition (SCADA) systems, distributed control systems (DCS), and other control system configurations such as programmable logic controllers (PLC) often found in the industrial sectors and critical infrastructures.” 

Why scan for ICS?

Governments often describe ICS as critical infrastructure; they are essential to societal and economic function. Their critical nature means changes, updates, and replacements are risky and costly endeavors. Put simply: ICSs are slow to change with a strong bias toward legacy technology and compatibility.

Many ICSs feature custom network serial-based protocols for coordinating industrial hardware. The rise of the modern internet came with worldwide networking standardization. Without security as a priority, many vendors simply packed their legacy protocols inside TCP or UDP and called their devices network or internet-ready. 

ICSs critical nature – combined with lagging security – incentivizes attackers and defenders to scan the internet for exposed devices. 

Can I see ICS scanning in GreyNoise?

GreyNoise Researchers have identified and created tags for the following ICS-related protocols:

• ‍Tridium NiagraAX Fox ICS Scanner
• ‍Veeder-Root ATGs Crawler
• ‍MQTT Protocol Scanner
• ‍Mitsubishi FX3U PLC Scanner
• ‍Phoenix Contact PLC Scanner
• ‍Digi RealPort Scanner
• ‍Modbus TCP/IP Scanner
• ‍Siemens S7Comm Protocol Scanner
• ‍Codesys Scanner
• ‍Distributed Network Protocol 3 (DNP3) Scanner
• ‍IEC 60870-5-104 Scanner
• ‍GE-SRTP Scanner
• ‍EtherNet/IP Scanner
• ‍HART-IP Scanner
• ‍MELSEC-Q Scanner
• ‍Omron FINS Scanner‍
• PCWorx Scanner‍
• ProConOS Scanner‍
• BACnet Scanner‍
• Crimson V3 Scanner‍
• IEC 61850-8-1 Scanner‍
• Moxa NPort Scanner‍
• Modicon PLC Scanner‍
• OPC UA Scanner

Next steps

Create a free account today to start researching ICS-related protocols and more.

How are GreyNoise Tags created?

GreyNoise tags are described in the documentation as “a signature-based detection method used to capture patterns and create subsets in our data.” The GreyNoise Research team is responsible for creating tags for vulnerabilities and activities seen in the wild by GreyNoise sensors. GreyNoise researchers have two main methods for tagging: a data-driven approach, and an emerging threats-driven approach. Each of these approaches has three main stages:

• Discovery
• Research
• Implementation

Data-driven approach

When using a data-driven approach, researchers work backward from the data collected by GreyNoise sensors. Researchers will manually browse data or create tooling to aid in finding previously untagged and interesting data. This method relies heavily upon intuition and prior expertise and has led to non-vulnerability-related discoveries such as a Holiday PrintJacking campaign. Using this approach, GreyNoise steadily works toward providing some kind of context for every bit of data opportunistically transmitted over the internet to our sensors.

During the discovery phase, researchers identify interesting data that does not appear to be tagged by manual or tool-assisted browsing of raw sensor data. Researchers will simply query the data lake for interesting words or patterns, using instinct to drive exploration of the data. Once they have identified and collected an interesting set of data, they begin the research phase.

During the research phase, the researcher works to identify what the data is. This could be anything from CVE-related traffic to a signature for a particular tool. They do this by scouring the internet for various paths, strings, and bytes to find documentation relating to the raw traffic. This often requires the researcher to be adept at reading formal standards, like Requests for Comments, as well as reading source code in a variety of programming languages. Once they have identified the data, the researcher will gather and document their findings before moving on to the implementation phase.

Using their research, the researcher will implement a tag by actually writing the signature and populating the metadata that makes it into a GreyNoise tag. Once complete, a peer will review the work, looking for errors in the signature and false positives in the results before clearing it for production.

Emerging threats approach

When using an emerging threats-driven approach, researchers seek out emerging threats observable by GreyNoise sensors. For the most part, GreyNoise only observes network-related vulnerability and scanning traffic. This rules out vulnerabilities like local privilege escalations. Using this method, GreyNoise can provide early warning for mass scanning or exploitation activity in the wild of things like CVE-2022-26134, an Atlassian Confluence Server RCE.

During the discovery phase, researchers monitor a wide variety of sources such as tech news outlets, social media, US CISA’s Known Exploited Vulnerabilities Catalog, and customer/community requests. Researchers identify and prioritize CVEs that customers and community members may be interested in due to their magnitude, targeted appliances, etc.

Similar to the data-driven approach, researchers will gather publicly available information regarding the emerging threat that will allow them to write a signature. Proof-of-Concept (PoC) code is often the most useful piece of information. On rare occasions, lacking a PoC, researchers will sometimes attempt to independently reproduce the vulnerability. Researchers will often attempt to validate vulnerabilities by setting up testbeds to better understand what elements of the vulnerability should be used to create a unique and narrowly scoped signature.

Finally, using all collected information, the researcher will seek to write the signature that becomes a tag. When doing this, researchers focus on eliminating false positives and tightly scoping the signature to the targeted data or vulnerability. When relevant for emerging threats, GreyNoise researchers will run this signature across all of GreyNoise’s historical data to determine the date of the first occurrence. This allows GreyNoise to publish information regarding when a vulnerability has first seen mass exploitation in the wild and, occasionally, if a vulnerability, like OMIGOD, was exploited before exploit details were publicly available.

How to use GreyNoise tags

GreyNoise provides insight into IP addresses that are scanning the internet or attempting to opportunistically exploit hosts across the internet. Tag data associated with a specific IP address provides an overview of the activity that GreyNoise has observed from a particular IP, as well as insight into the intention of the activity originating from it. For example, we can see that this IP is classified as malicious in GreyNoise because it is doing some reconnaissance but also has tags associated with malicious activity attempting to brute force credentials as well as traffic identifying it as part of the Mirai botnet.

‍

GreyNoise tags are also a great way to identify multiple hosts that are scanning for particular items or CVEs. For example, querying for a tag and filtering data can show activity related to a CVE that is originating from a certain country, ASN, or organization. This gives a unique perspective on activity originating from these different sources. 

‍

Finally, tag data is accessible via the GreyNoise API and allows integrations to add this tag data easily into other products.

‍

See which tags are trending right now.

‍