UPDATE 16-Dec-21, 4:00 PM ET: Tentative results for #Log4Shell activity by hour showing "Researcher" and "Non-Researcher" breakdown as observed by GreyNoise. It may not be 100% accurate, but it should give an idea of what we are observing. "Researcher" is defined by IPs that GreyNoise knows to be attributable scanners for commercial or research purposes, usually listed as "benign" in our data. "Non-Researcher" is defined as everything else. The researcher numbers seem to flatline, but we believe this is due to the scale of the plot, and new infrastructure spun up by various researchers that have not yet been accounted for. We will try to update this later for a better retroactive understanding.
UPDATE 16-Dec-21, 1:00 PM ET: GreyNoise Research has compiled a set of sample Log4Shell (CVE-2021-44228) payloads observed in the wild. These samples are intended to provide individuals with a clearer idea of some of the variation we're seeing, including esoteric protocols such as IIOP. https://gist.github.com/nathanqthai/197b6084a05690fdebf96ed34ae84305
UPDATE 15-Dec-21, 11:00 PM ET: As of 15-Dec-21, GreyNoise Research is seeing a decrease in the number of unique IP addresses scanning for the Apache Log4j vulnerability.
On December 5, 2021, Apache identified a vulnerability (later identified as CVE-2021-44228) in their widely used Log4j logging service. The vulnerability, also known as Log4shell, enables attackers to gain full control of affected servers by allowing unauthenticated remote code execution if the user is running an application utilizing the Java logging library. Log4j is heavily integrated into a broad set of DevOps frameworks, enterprise IT systems, and vendor software and cloud products.
GreyNoise first observed activity for this vulnerability on December 9, 2021, from 194.48.199[.]78 and 181.214.39[.]2.
To get a current list of all the IP addresses opportunistically scanning the internet to vuln check or exploit CVE-2021-44228, check out this tag summary in the GreyNoise Visualizer
“The reason this vulnerability matters is that Log4j is heavily integrated in enterprise IT and devops. There are a whole bunch of devops frameworks and a whole bunch of enterprise IT systems and vendor systems that use it. So if you pick basically any large vendor and stick Log4j in Google, you’ll find it kicking around in different products, which is going to become a problem. There’s clearly lots of systems out there that, in some way shape or form, rely on this.” – Kevin Beaumont (@GossiTheDog, via Twitter Spaces recording)
On December 5th, 2021, Apache filed a JIRA issue identifying the vulnerability that would become CVE-2021-44228. The following day, December 6th, Apache released a patch providing some details on the vulnerability and crediting Chen Zhaojun of Alibaba Cloud Security Team for the discovery.
On December 9th, weaponized proof-of-concept exploits (PoCs) began to appear, leading to a rapid increase of scanning and public exploitation on December 10th.
Between 1200 EST and 1400 EST on December 10, 2021, GreyNoise has observed a 5x increase in the number of hits per sensor related to the Log4shell event.
Due to ease of exploitation and prevalence of Log4J, GreyNoise researchers believe that this activity will continue to increase over the next few days. A wide variety of use cases for this exploit have already begun to appear, ranging from exploiting Minecraft servers
to more high-profile issues potentially affecting Apple iCloud
The vulnerability feels similar to ShellShock, a vulnerability GreyNoise still observes since it was first identified in 2014.
GreyNoise is providing IOCs for CVE-2021-44228 Apache Log4j RCE attempts on Github. You can access the C2/Callback domains here and the latest IPs here. You can get the most up-to-date information via GreyNoise for Log4shell here.
CVE-2021-44228 is still new, and its impact will likely be felt for a long time due to the pervasiveness of Log4j. Multiple recommendations for patching have been made (CISA), and detections have been made available. As the landscape develops, GreyNoise will be tweeting about new information and IoCs. Follow us there for the latest information.
On November 24, 2021, GreyNoise’s passive sensor network observed a single IP address mass transmitting a message in plaintext to port 9100, a common port for printer connections. The text is related to Reddit’s /r/antiwork, a subreddit dedicated to discussing and seeking an end to exploitative work. Since the initial observation, we’ve seen a significant increase in transmissions.
Printers, when exposed to the Internet over port 9100, will print any plaintext received. As seen in Figure 1, this message was formatted with the proper dimensions specifically for receipt printers. This appears to be corroborated by a dozen individuals posting printed receipts from their place of work with variations of the messages observed by GreyNoise, Figure 1. GreyNoise has seen 29 variations of the same few messages, which have been provided at the end of this blog.
The observed activity began with reconnaissance. GreyNoise saw several actors performing network scans using Nmap, ZMap, and masscan to verify that port 9100 is open before relaying r/antiwork messages. Figure 2 shows the timeline of activity, with activity coming from over 60+ unique IPs over the span of the week.
The bulk of activity originates from IPs belonging to “BL Networks," a hosting provider based out of the Netherlands (view it on GreyNoise). Figure 3 shows the geographical breakdown of IPs transmitting the messages.
While the messages are not specific to the United States, the majority of the traffic was largely directed at North American IPs.
The GreyNoise Research team was able to identify at least one concerted effort behind the recent activity. Figure 4 shows individual IP activity observed by GreyNoise sensors over time. IPs are colored by their numerical adjacency. For example, 192.168.1.1 and 192.168.1.2 would be colored similarly since they are numerically adjacent, but 10.0.0.1 and 192.168.1.1 are not.
Researchers observed a diverse set of uncoordinated IP addresses responsible for the activity around Thursday, November 25 (U.S. Thanksgiving) and Friday, November 26 (Black Friday). Prior to November 26, activity was scattered amongst different source IPs and ASN ranges. However, in the following week, we noted two additional sets of coordinated IPs on November 29th and December 2.
Researchers determined that, as of December 2nd, all servers used to transmit the messages had port 80 open and were running Python 3.9.2 SimpleHTTPServer. The servers exposed a directory with the text files, presumably the content being transmitted by the server:
Based on associated SSL Certificates and domain information, the team was able to make contact with the current owner of one of the IPs. The owner responded with the following:
GreyNoise researchers were unable to determine whether or not the current owner is responsible for the activity, though they did respond letting us know they took down one of the servers (which GreyNoise has corroborated).
This is not the first time printjacking has occurred. GreyNoise has previously observed coordinated activity on port 9100 in 2018 related to an incident involving YouTube superstar PewDiePie.
When asked for recommendations on best practices, GreyNoise IT & Security Director responded: “In order to avoid printjacking, we recommend ensuring port 9100 on your device remains closed to the Internet. If your printer vendor requires connection to an open port, it’s a good time to consider a different provider."
Learn more about GreyNoise and follow us on LinkedIn and Twitter.
GreyNoise has seen 29 variations of the same few messages, which you can read below or access via this Gist.
RIDDLE ME THIS
How can the McDonald's in Denmark manage
to pay their staff $22 an hour and still
sell a Big Mac for less than in America?
Answer: UNIONS!
Did you know that it is a rather
simple task to organize a UNION?
Learn More:
=====================
reddit.com/r/antiwork
=====================
----------------------------------------------------------
ARE YOU BEING UNDERPAID?
You have a legal, protected right to discuss your pay with your coworkers.
This should be done on a regular basis to ensure that everyone is being paid fairly.
It is ILLEGAL for your employer to punish you for doing this.
If you learn that you are being paid less than someone else who is doing the same job,
you should demand a raise or consider quitting and finding a different job.
SLAVE WAGES only exist because people are willing to work for them.
Learn More:
=====================
reddit.com/r/antiwork
=====================
----------------------------------------------------------
======================
NEW YEAR'S RESOLUTIONS
======================
1. Hit the Gym
2. Delete Facebook
3. ORGANIZE A UNION
Learn More:
=====================
reddit.com/r/antiwork
=====================
----------------------------------------------------------
=========================
WHAT TO DO ON BREAK TODAY
=========================
1. Talk about your PAY
2. Talk about your RIGHTS
3. Begin ORGANIZING A UNION
GOOD employers are not afraid
of these, but ABUSIVE ones are.
Learn More:
=====================
reddit.com/r/antiwork
=====================
----------------------------------------------------------
=====================
INFLATION WAGE NOTICE
=====================
Due to the 6.2% inflation rate,
all US workers are entitled to
at least a 6.2% pay adjustment.
We have received reports of
some ABUSIVE EMPLOYERS not
providing these adjustments.
If you have not received such a
raise, please ask your employer
why your PAY WAS CUT.
Learn More:
=====================
reddit.com/r/antiwork
=====================
----------------------------------------------------------
=========================
WHAT TO DO ON BREAK TODAY
=========================
1. Talk about your PAY
2. Talk about your RIGHTS
3. Begin ORGANIZING A UNION
GOOD employers are not afraid
of these, but ABUSIVE ones are.
Learn More:
=====================
reddit.com/r/antiwork
=====================
----------------------------------------------------------
TIME IS YOUR MOST VALUABLE ASSET.
Not only can you never obtain any
more of it, you do not even know
how much you have to begin with.
Why are you selling YOUR TIME
for SO LITTLE?
Join the "25 OR WALK" movement!
Tell your employer that YOUR TIME
is worth no less than $25 per hour,
and for them to call you when
they are ready to pay up.
But don't quit!
Make them fire you!
... and spend YOUR TIME with family
... and spend YOUR TIME with friends
... and rediscover YOUR favorite hobby
... and RECLAIM YOUR LIFE
SLAVE WAGES only existed because
people were willing to work for them.
BUT NOT ANYMORE.
THIS. ENDS. NOW.
Learn More:
=====================
reddit.com/r/antiwork
=====================
----------------------------------------------------------
HOW TO SCARE A SLAVE OWNER:
1. Talk about your PAY
2. Talk about your RIGHTS
3. Talk about FORMING A UNION
Employers are not scared of
these, but SLAVE OWNERS are.
Learn More:
=====================
reddit.com/r/antiwork
=====================
----------------------------------------------------------
==========================
ABUSIVE EMPLOYER CHECKLIST
==========================
[ ] Can't talk about PAY
[ ] Can't talk about RIGHTS
[ ] Can't talk about UNIONS
[ ] Punished for getting SICK
[ ] Punished for taking VACATION
If your employer checks ANY of
these, please contact support:
reddit.com/r/antiwork
----------------------------------------------------------
:::::::::::::::::::::::::::::::
::::: TIME IS :::::::::::::::::
::::::: YOUR MOST :::::::::::::
:::::::::: VALUABLE ASSET :::::
:::::::::::::::::::::::::::::::
Not only can you never
obtain any more of it,
you do not even know how
much you have to begin with.
LIFE IS SHORT!
Why are you selling YOUR TIME
for SO LITTLE?
Join the "25 OR WALK" movement!
Tell your employer that YOUR
TIME is worth no less than
$25 per hour, and for them
to call you when they are
ready to pay up.
But DON'T QUIT!
MAKE THEM FIRE YOU!
... and spend YOUR TIME
...... with FAMILY
... and spend YOUR TIME
...... with FRIENDS
... and rediscover YOUR
...... FAVORITE HOBBY
... AND RECLAIM YOUR LIFE
POVERTY WAGES only existed
because people were "willing"
to work for them.
BUT NOT ANYMORE.
THIS. ENDS. NOW.
Learn More:
=====================
reddit.com/r/antiwork
=====================
----------------------------------------------------------
ARE YOU BEING UNDERPAID?
You have a legal, protected right to
discuss your pay with your coworkers.
This should be done on a regular basis to
ensure that everyone is being paid fairly.
It is ILLEGAL for your employer to punish
you for doing this.
If you learn that you are being paid less
than someone else who is doing the same
job, you should demand a raise or consider
getting fired and finding a better job.
SLAVE WAGES only exist because people are
willing to work for them.
Learn More:
=====================
reddit.com/r/antiwork
=====================
----------------------------------------------------------
==============
RIDDLE ME THIS
==============
How can the McDonald's
in Denmark pay their staff
$22 an hour and still manage
to sell a Big Mac for
less than in America?
Answer: UNIONS!
A GOOD UNION can easily
align everyone's goals.
Did you know that it
is a rather simple task
to organize a UNION?
Learn More:
=====================
reddit.com/r/antiwork
=====================
----------------------------------------------------------
========================
ARE YOU BEING UNDERPAID?
========================
You have a protected LEGAL
RIGHT to discuss your pay
with your coworkers.
This should be done on a
regular basis to ensure that
everyone is being paid fairly.
It is ILLEGAL for your employer
to punish you for doing this.
If you learn that you are being
paid less than someone else who
is doing the same job, you
should demand a raise or
consider getting fired and
finding a better employer.
POVERTY WAGES only exist
because people are "willing"
to work for them.
Learn More:
=====================
reddit.com/r/antiwork
=====================
----------------------------------------------------------
RIDDLE ME THIS
How can the McDonald's in Denmark manage
to pay their staff $22 an hour and still
sell a Big Mac for less than in America?
Answer: UNIONS!
Did you know that it is a rather
simple task to organize a UNION?
Learn More:
=====================
reddit.com/r/antiwork
=====================
----------------------------------------------------------
=====================
INFLATION WAGE NOTICE
=====================
Due to the 6.2% inflation rate,
all US workers are entitled to
at least a 6.2% pay adjustment.
We have received reports of
some ABUSIVE EMPLOYERS not
providing these adjustments.
If you have not received such a
raise, please ask your employer
why your PAY WAS CUT.
Learn More:
=====================
reddit.com/r/antiwork
=====================
----------------------------------------------------------
RIDDLE ME THIS
How can the McDonald's in Denmark manage
to pay their staff $22 an hour and still
sell a Big Mac for less than in America?
Answer: UNIONS!
Did you know that it is a rather
simple task to organize a UNION?
Learn More:
=====================
reddit.com/r/antiwork
=====================
----------------------------------------------------------
========================
ARE YOU BEING UNDERPAID?
========================
You have a protected LEGAL
RIGHT to discuss your pay
with your coworkers.
This should be done on a
regular basis to ensure that
everyone is being paid fairly.
It is ILLEGAL for your employer
to punish you for doing this.
If you learn that you are being
paid less than someone else who
is doing the same job, you
should demand a raise or
consider getting fired and
finding a better employer.
POVERTY WAGES only exist
because people are "willing"
to work for them.
Learn More:
=====================
reddit.com/r/antiwork
=====================
----------------------------------------------------------
==========================
ABUSIVE EMPLOYER CHECKLIST
==========================
[ ] Can't talk about PAY
[ ] Can't talk about RIGHTS
[ ] Can't talk about UNIONS
[ ] Punished for getting SICK
[ ] Punished for taking VACATION
If your employer checks ANY of these,
please contact support at:
reddit.com/r/antiwork
----------------------------------------------------------
TIME IS YOUR MOST VALUABLE ASSET.
Not only can you never obtain any
more of it, you do not even know
how much you have to begin with.
Why are you selling YOUR TIME
for SO LITTLE?
Join the "25 OR WALK" movement!
Tell your employer that YOUR TIME
is worth no less than $25 per hour,
and for them to call you when
they are ready to pay up.
But don’t quit!
Make them fire you!
... and spend YOUR TIME with family
... and spend YOUR TIME with friends
... and rediscover YOUR favorite hobby
... and RECLAIM YOUR LIFE
SLAVE WAGES only existed because
people were willing to work for them.
BUT NOT ANYMORE.
THIS. ENDS. NOW.
Learn More:
=====================
reddit.com/r/antiwork
=====================
----------------------------------------------------------
TIME IS YOUR MOST VALUABLE ASSET.
Not only can you never obtain any
more of it, you do not even know
how much you have to begin with.
Why are you selling YOUR TIME
for SO LITTLE?
Join the "25 OR WALK" movement!
Tell your employer that YOUR TIME
is worth no less than $25 per hour,
and for them to call you when
they are ready to pay up.
But don’t quit!
Make them fire you!
... and spend YOUR TIME with family
... and spend YOUR TIME with friends
... and rediscover YOUR favorite hobby
... and RECLAIM YOUR LIFE
SLAVE WAGES only existed because
people were willing to work for them.
BUT NOT ANYMORE.
THIS. ENDS. NOW.
Learn More:
=====================
reddit.com/r/antiwork
=====================
----------------------------------------------------------
HOW TO SCARE A SLAVE OWNER:
1. Talk about your PAY
2. Talk about your RIGHTS
3. Talk about FORMING A UNION
Employers are not scared of
these, but SLAVE OWNERS are.
Learn More:
=====================
reddit.com/r/antiwork
=====================
----------------------------------------------------------
======================
NEW YEAR'S RESOLUTIONS
======================
1. Hit the Gym
2. Delete Facebook
3. ORGANIZE A UNION
Learn More:
=====================
reddit.com/r/antiwork
=====================
----------------------------------------------------------
HOW TO SCARE A SLAVE OWNER:
1. Talk about your PAY
2. Talk about your RIGHTS
3. Talk about FORMING A UNION
Employers are not scared of
these, but SLAVE OWNERS are.
Learn More:
=====================
reddit.com/r/antiwork
=====================
----------------------------------------------------------
ARE YOU BEING UNDERPAID?
You have a legal, protected right to
discuss your pay with your coworkers.
This should be done on a regular basis to
ensure that everyone is being paid fairly.
It is ILLEGAL for your employer to punish
you for doing this.
If you learn that you are being paid less
than someone else who is doing the same
job, you should demand a raise or consider
quitting and finding a different job.
SLAVE WAGES only exist because people are
willing to work for them.
Learn More:
=====================
reddit.com/r/antiwork
=====================
----------------------------------------------------------
:::::::::::::::::::::::::::::::
::::: TIME IS :::::::::::::::::
::::::: YOUR MOST :::::::::::::
:::::::::: VALUABLE ASSET :::::
:::::::::::::::::::::::::::::::
Not only can you never
obtain any more of it,
you do not even know how
much you have to begin with.
LIFE IS SHORT!
Why are you selling YOUR TIME
for SO LITTLE?
Join the "25 OR WALK" movement!
Tell your employer that YOUR
TIME is worth no less than
$25 per hour, and for them
to call you when they are
ready to pay up.
But DON'T QUIT!
MAKE THEM FIRE YOU!
... and spend YOUR TIME
...... with FAMILY
... and spend YOUR TIME
...... with FRIENDS
... and rediscover YOUR
...... FAVORITE HOBBY
... AND RECLAIM YOUR LIFE
POVERTY WAGES only existed
because people were "willing"
to work for them.
BUT NOT ANYMORE.
THIS. ENDS. NOW.
Learn More:
=====================
reddit.com/r/antiwork
=====================
----------------------------------------------------------
ARE YOU BEING UNDERPAID?
You have a legal, protected right to
discuss your pay with your coworkers.
This should be done on a regular basis to
ensure that everyone is being paid fairly.
It is ILLEGAL for your employer to punish
you for doing this.
If you learn that you are being paid less
than someone else who is doing the same
job, you should demand a raise or consider
getting fired and finding a better job.
SLAVE WAGES only exist because people are
willing to work for them.
Learn More:
=====================
reddit.com/r/antiwork
=====================
----------------------------------------------------------
==========================
ABUSIVE EMPLOYER CHECKLIST
==========================
[ ] Can't talk about PAY
[ ] Can't talk about RIGHTS
[ ] Can't talk about UNIONS
[ ] Punished for getting SICK
[ ] Punished for taking VACATION
If your employer checks ANY of
these, please contact support:
reddit.com/r/antiwork
----------------------------------------------------------
ARE YOU BEING UNDERPAID?
You have a legal, protected right to
discuss your pay with your coworkers.
This should be done on a regular basis to
ensure that everyone is being paid fairly.
It is ILLEGAL for your employer to punish
you for doing this.
If you learn that you are being paid less
than someone else who is doing the same
job, you should demand a raise or consider
getting fired and finding a better job.
SLAVE WAGES only exist because people are
willing to work for them.
Learn More:
=====================
reddit.com/r/antiwork
====================
----------------------------------------------------------
==============
RIDDLE ME THIS
==============
How can the McDonald's
in Denmark pay their staff
$22 an hour and still manage
to sell a Big Mac for
less than in America?
Answer: UNIONS!
A GOOD UNION can easily
align everyone's goals.
Did you know that it
is a rather simple task
to organize a UNION?
Learn More:
=====================
reddit.com/r/antiwork
=====================
GreyNoise is proud to announce a production contract with a $30M USD ceiling awarded to GreyNoise by the United States Department of Defense (U.S. DoD). This new contract stems from GreyNoise’s initial prototype with the U.S. DoD’s Defense Innovation Unit (DIU) announced earlier in 2021 to help the Department diagnose internet-wide scan-and-attack activity.
Our CEO and Founder, Andrew Morris, says it best: “We're deeply thrilled to be able to call the DoD a full customer, and honored to support their mission…we have become the ‘go-to’ authority on the scan-and-attack traffic that absolutely all internet-dependent organizations are subject to, because of our unique ability to monitor and analyze internet noise at global scale. This visibility has become more and more important as malicious actors leverage automation to scale their attacks. GreyNoise will enhance cyber threat detection and intelligence-gathering capabilities across the DoD and other branches of the U.S. government, and enable security analysts to focus their valuable time and energy on legitimate threats.”
Every machine connected to the internet is exposed to a barrage of unsolicited communications from tens of thousands of unique IP addresses per day—a phenomenon we call internet background noise. A percentage of these communications are malicious attacks and web crawls; some are non-malicious scans and pings; some are legitimate business services; and others still are unknown, but hitting everyone on the internet. GreyNoise solves the challenge of diagnosing and filtering this massive volume of traffic for security analysts and teams.
GreyNoise offers two value propositions for security analysts and SOC teams:
We help SOC teams recognize events not worth their attention. On average, prospects who trial GreyNoise see that 20-40% of their alert traffic is noise, and GreyNoise customers are seeing alert volume reductions of 25% or more.
Indicators in GreyNoise are likely associated with opportunistic internet scanning or common business services, not targeted threats. This context helps the SOC in a few ways:
GreyNoise helps organizations reduce the risk and costs of compromise by seeing emerging threats faster and more clearly, in three basic ways:
This production contract allows the GreyNoise platform to be purchased and utilized by all DoD organizations over a 5-year period. Resulting from our partnership with the Defense Innovation Unit (DIU), the collaboration helps the DoD focus on identifying and scaling commercial technology solutions while deploying them rapidly across the U.S. military to strengthen the nation’s security.
We’ve got an ordering guide that makes it easy for DoD organizations to scope and purchase the GreyNoise platform for their specific requirements. To access the ordering guide for GreyNoise products associated with this contract, please email sales@greynoise.io.
You’re in a dark room, and your screen is crawling with alerts from your IDS/IPS about an IP address trying an exploit on one of your internet-facing devices. You scramble to investigate the event, checking VirusTotal, IPinfo, Whois, and even Google to try to figure out how dangerous the IP might be, only to figure out after an hour that it's actually just Shodan… or Censys… or Pingdom… or a brain-dead bot script.
GreyNoise recently met with Robert*, Manager of Cybersecurity Incident Response & Operations at a large food service & hospitality company. Robert lives this reality every day as he and his Incident Response team respond to network events from their MSSP and internal detections. Recently Robert found a way to leverage GreyNoise Intelligence data integrated into Cortex XSOAR incident response to help his team answer these questions much more quickly and effectively. We caught up with Robert recently to learn how he had done it.
* Customer names have been changed to maintain anonymity
Robert: Sure — I lead the incident response and security operations team at my company. I've been here for about six years and was previously an individual contributor on a joint team that combined security engineering, incident response, and security operations.
A few years ago, we figured it probably doesn't make sense to keep this one giant team, and it would be nice to start developing some specialization. So we chunked the team into two groups — a security engineering team, and an incident response and security operations team. I was fortunate to be selected to run the new IR and Ops team, and I’ve been doing it for about two years now.
Robert: We work with several external partners that triage alerts for us, as well as conduct our own custom detections and investigations. We actually have four different alert classifications:
So basically, we use our MSSP partner as Tier 1 analysts, with my teams handling Tier 2 and above. We're not a 24x7 shop, so we push 24x7 monitoring of our assets to our partners, basically saying, “Here's your escalation plan during business hours; here's your escalation plan outside of business hours. Go get them.”
Once we get an alert through any of these sources, we'll do triage, and beyond the initial triage, we’ll do remediation, and then resilience. Any kind of gaps that we have in those tools, we supplement with our own detections, or if it's a use case that’s specific to the company, we'll do it internally as well.
Robert: I remember seeing Andrew [Morris, founder and CEO of GreyNoise] talking about it on Twitter, and I checked it out and thought, wow, this is really awesome. I think the biggest sort of “aha” for me was looking at the amount of time it could save me during an investigation.
What was happening quite often to us was that we would get these IDS/IPS alerts about an exploitation attempt. And we’d have to run the alerts to the ground, and it was taking forever.
I realized, looking at GreyNoise, that this tool would tell me if this is a targeted attack or if it’s a piece of automation that some attacker is using to try to build their botnet. Because if it's an automated attack, and the script fails even slightly, then the whole attack is probably a wash at that point. There's not an operator with hands-on-keyboard to make the adjustments needed, so the automation just fails and moves on to the next IP.
Having that kind of insight was a game-changer for us in how we analyzed those alerts and how we looked at that type of attack surface. So we started using the Community edition of GreyNoise with our old homegrown incident response tool to query things, and it was tremendously helpful.
For example, one of the things we were looking at was vulnerability scans. If we’re getting vulnerability scanned by somebody who’s scanning everybody else too, okay, welcome to the Internet. But if somebody’s scanning us that GreyNoise has never heard of, that's interesting — why are they just scanning us? Are we being targeted? GreyNoise majorly short-cycled a lot of investigations on these kinds of events.
Another example, we would see somebody slinging an Apache Struts exploit. Okay, are they doing this just to us, or are they doing this to everybody? And again, that kind of changed the dynamic of how we responded to that event.
Robert: A while back, we started to look at various SOAR platforms, and I ended up doing evaluations of what was then Demisto (it’s Cortex XSOAR now), Splunk Phantom, Swimlane, and Siemplify. I engaged with the vendors, downloaded the software, ran an evaluation environment, and actually kicked the tires on each of them. Ultimately we landed on XSOAR, and that started the clock of bringing things over from our existing incident response queue.
As we started to bring events into XSOAR, particularly the ones where we had been using GreyNoise, I realized there was a great opportunity to integrate GreyNoise into XSOAR to automate the process. I went to my director and made the case that we've been using this tool called GreyNoise, and it's super helpful. Now that we've got these events coming from our MSSP into XSOAR, we could start leveraging automation to query GreyNoise, instead of having to manually copy the IP, open up a new tab, paste it in and run a search.
I had been talking to Andrew a fair amount on Twitter, and he sent me over an integration between GreyNoise and XSOAR (there was no marketplace at the time), and it worked really well. So we signed up for a paid plan with GreyNoise to get more IP lookups and more context information. We now use GreyNoise on most of our network detection-based alerts to give context and alleviate a lot of strain from a research perspective on those events. So it's been great.
The way we’ve integrated GreyNoise into XSOAR is that any time we see an IP address, XSOAR invokes the IP enrichment command for every integration that supports it. This includes GreyNoise, Virus Total, IPinfo.io, whatever. It'll run them all, bring all that data back, and show it to the analyst. One of the areas where GreyNoise is really useful with this approach is inside of our playbook for the IDS/IPS alerts from our MSSP.
In addition to alerts coming from our MSSP, we do custom detections in our SIEM, Splunk Enterprise Security. So while we will write content in Splunk, and raise these as notable events in ES, all of the results get mirrored into XSOAR. We try to make XSOAR the “one-stop-shop” for every event that we’re working.
Robert: Just being able to tell the background noise of the Internet, that was huge for us and made us go “wow.” To see that this activity is just a consequence of being online, but that activity over there GreyNoise hadn't seen, so they're only paying attention to us, and it actually merits us looking into more deeply because they're not just slinging exploits or vulnerability scans at every IP address on the Internet. And we've also seen the opposite, where we see yes, they are a benign scanner, and it's Shodan, cool, we can ignore it.
Because GreyNoise is good at providing context around what IPs are doing in the broader Internet, it typically plays a lot with the IDS/IPS stuff that our MSSP handles — the primary data that we pivot off of for these events is the IP address. We also use GreyNoise on an ad hoc basis — for example, if I see a weird IP on a login to our identity provider, I’ll look it up in GreyNoise and see if it does anything funky on the Internet. And so it's often just helpful context.
Another use case that’s been really helpful is the new RIOT tagging, which identifies known legitimate traffic. For example, if I'm doing an investigation on a host that's been compromised and I've got a list of IPs it's talked to in the last 24 hours, I just want to rip out all the stuff that is legitimate, like Office 365 or Slack or cloud solutions that our users should be talking to. I can go to the analysis page on GreyNoise and just drop this big block of IPs in there, and it will tell me if any of these are ones that I should really be caring about, and help me eliminate the ones that I don’t. It gives me a good way to filter for a first pass — I can rule this stuff out for now and focus on what's left. Then if I still can't find anything, I can go back to the Office 365 IP and look for anomalies there. Because If there's an Eastern European IP address buried in amongst the Office 365 ones, I know which one I want to look at first.
Robert: Every time we find an IP that GreyNoise knows about, we ask ourselves, “Hey, is this IP trying to exploit CVE fill-in-the-blank here? Do we run that software? No? OK, done.” Because it's an opportunistic scanner, and GreyNoise is saying the IP is focused on this particular CVE, or it loves these six CVEs for this product suite. This allows us to conclude that, because we don't use that product suite, we're good, and we can ignore it.
Alternatively, the answer might be, “yes, we do use that product suite.” In that case, I’ll go read about the CVE and see what versions are vulnerable, and then look at our system and see if it’s something we need to dig into or whether we already patched for it.
As part of our triage, we also check in with our vulnerability management team. If we see a scanner out on the Internet scanning through our IPs, we’ll go dig up our internal scan results for the same IP and see what we found. Because we can pretty much know that anything we found, the bad guys just did too.
There’s some nice visibility we get with GreyNoise around vulnerability scans. For example, for events that we get, we can look at our firewall and easily see that this particular IP scans all of these public IPs. Then we can check in GreyNoise to see, what ports does this scanner like to scan? We obviously know they scan port 80 because that's why we're here. But do they scan 443 (SSL)? Recently Andrew tweeted about some new behavior GreyNoise tracks looking at whether scanners follow 301 or 302 redirects.
Say we determine that this IP only scans port 80 — cool. Now we can go into XSOAR and CURL all of the IPs that they scanned on port 80 and check to see if there’s a common vulnerability they might be looking for. Or do we get our load balancer telling them they need to go to 443? Because if we get that, and this IP doesn’t follow redirects, and this IP doesn't scan 443, then he's hitting a load balancer appliance, and I don't care. In XSOAR, that playbook will close the event if this is the condition that's met. And no analyst ever has to interact with this event.
Robert: I remember first seeing Andrew talking about GreyNoise on Twitter. When I checked it out, I thought, wow, this is really awesome. I think the biggest sort of “aha” for me was looking at the amount of time it could save me during an investigation.
We started using the GreyNoise Community edition with our old homegrown incident response tool, and it was tremendously helpful. That experience allowed me to go to my director and make a case for leveraging automation to query GreyNoise, instead of having to manually copy the IP, open up a new tab, paste it in and run a search. Today we use GreyNoise on most of our network detection-based alerts, and to enrich every event we get from our MSSP. I would estimate that GreyNoise is saving us probably an hour of work every time we get one of these vulnerability scan events — we’ve automated our approach completely, so an analyst doesn’t even have to touch it (and we see around 8-10 of these events every week). So long story short, GreyNoise really does shorten the cycle of some of these vulnerability scan investigations and is saving us about 40 hours per month that we can apply to other high-priority security problems.
I’m also getting some good value out of using GreyNoise for ad hoc investigation context help — for example, when I've got a bunch of IPs and I just want to filter out the ones that I don't need to care about. We use GreyNoise to give context and alleviate a lot of strain from a research perspective on those events. So it's been great.
Curious how GreyNoise can save your SOC time? Try the product for free.
GitLab CE RCE Attempt [Intention: Malicious]
Apache Storm Supervisor RCE Attempt [Intention: Malicious]
Hikvision IP Camera RCE Attempt [Intention: Malicious]
SonicWall SMA100 Factory Reset Attempt [Intention: Malicious]
SonicWall SSL-VPN RCE Attempt [Intention: Malicious]
Legacy Web Server RCE Attempt [Intention: Malicious]
D-Link DIR-825 R1 RCE Attempt [Intention: Malicious]
D-Link DNS-320 RCE Attempt [Intention: Malicious]
Micro Focus OBR RCE Attempt [Intention: Malicious]
Yealink Device Management RCE Attempt [Intention: Malicious]
Wednesday, October 20, 2021, is the first ever SOC Analyst Appreciation Day™ - and in our opinion, it couldn’t have come sooner! We’d like to acknowledge the hard work and dedication of all the SOC analysts who help defend institutions across the globe. Thank you.
A SOC analyst’s life can be frustrating and stressful, with the weight of your organization’s security on your shoulders. Our goal here at GreyNoise is to help make your life easier by increasing SOC analyst efficiency, and by telling teams what not to worry about. We do this by helping you filter out “noisy” alerts associated with opportunistic internet scanning or common business services, not targeted threats. SOC teams can use GreyNoise data by using our web-based Visualizer, accessing our API via REST, SDK, or CLI, or integrating directly with your security tech stack.
If you’re a SOC analyst or manager interested in learning more about how you can use GreyNoise
On October 4th, 2021, Apache disclosed a path traversal vulnerability CVE-2021-41773 that affects HTTP Server version 2.4.49. The vulnerability was introduced in this version (2.4.49) and is patched in version 2.4.50.
This path traversal vulnerability allows sensitive files outside of the expected document root to be accessed, such as configuration files and Common Gateway Interface (CGI) scripts. This allows for specially crafted requests to read arbitrary files as well as perform Remote Code Execution (RCE) on systems that have the Apache “mod_cgi” module enabled.
On October 3rd, 2021, at 08:44 UTC, GreyNoise observed the first scan for this vulnerability from 36.68.53.196. This predates the mailing list announcement from Apache on October 5th as well as the release of 2.4.50 on October 4th, but after the patch was committed on September 29th. [View 36.68.53.196 in GreyNoise]
As of October 5th, 2021, the first Proof of Concept (POC) code became available which demonstrated arbitrary file read. It was closely followed by a POC demonstrating RCE.
GreyNoise has released the following tag to enable monitoring of relevant activity:
As of 7-Oct-21, GreyNoise is seeing 47 unique IP addresses that have scanned for this vulnerability, 39 of which are “malicious” and 8 of which are “benign."
* Editor’s Note: If this tag returns “No results found’,' this means that GreyNoise has not observed any IP addresses scanning the internet for this CVE in the past 90 days. You can use GreyNoise to notify you if this changes by using our Alerts feature.
10/15/21: This blog has been updated with Figure 1 to depict the timeline of events.
Today at GreyNoise, we’re thrilled to announce our selection as the Most Innovative Security Solution of 2021, as recognized by the Tech Ascension Awards. The awards are starting to pile up at GreyNoise, and our team's excitement grows after repeated confirmation from analysts and customers. As the name of the award implies, this honor is granted to those proving themselves innovative in the tech community around specific criteria. GreyNoise was selected from a pool of more than 500 applicants for excellence in technology innovation, market research, and unique competitive differentiators.
Our CEO and Founder, Andrew Morris, welcomes the industry compliment: “…we are honored by all of this validation, as it shows that we are making progress toward our ultimate mission—to solve the problem of alert fatigue and information overload in the cybersecurity arena. Every day, we see a staggering number of internet scans barraging internet-facing computers and software, and generating massive volumes of security alerts. Some of this activity is malicious, but a significant amount is not, and it’s getting to the point where it’s tough for security analysts to discern real threats from background noise. GreyNoise enables security teams to focus on the threats that really matter, rather than wasting their time investigating insignificant alerts. This is the heart of what makes GreyNoise an innovative security solution: we sift the haystack so you can pay attention to the needles."
Because the Tech Ascension Awards are innovation-centered, best-in-class vendors that receive recognition solve critical industry challenges differently. “The proliferation of ransomware, nation-state threats, and an uptick in cybercriminal activity due to COVID-19 are just some of the factors that have made a strong cybersecurity defense paramount for every business that touches sensitive data,” said David Campbell, CEO of Tech Ascension Awards. “We’re honored to recognize these industry leaders that have demonstrated their ability to defend organizations with unique approaches, innovative technology, and world-class talent.”
Here are some of our most recent accolades:
Try GreyNoise for free, and find out for yourself why we are the "Most Innovative Security Solution."
Azure OMI RCE Attempt [Intention: Malicious]
Azure OMI RCE Check [Intention: Unknown]
VMWare VCSA File Upload Attempt [Intention: Malicious]
VMWare VCSA File Upload Check [Intention: Unknown]
LDAP Crawler [Intention: Unknown]
Veeder-Root ATGs Crawler [Intention: Unknown]
VMware vCenter File Disclosure [Intention: Malicious]
PJL Crawler [Intention: Unknown]
PowerShell Generic Shell Attempt [Intention: Malicious]
Cisco IMC Supervisor and UCS Director Backdoor [Intention: Malicious]
Our research team is always looking for ways to improve our tagging methodology to enable GreyNoise users to understand actor behavior and tooling. GreyNoise already identifies clients with JA3 and HASSH data.
To expand on this work, GreyNoise recently added 3 new tags to shed more light on how various internet background noise-makers using HTTP clients manage their internal state. The below tags improve client fingerprinting for HTTP-based protocols.
On their own, each individual tag contributes a small indication of how the HTTP client manages its internal state. While that alone has value in helping to profile the actor behind the IP and possibly track them across IPs, the more interesting insights can be seen when these tags are viewed holistically.
As seen above, the tagged activity is not homogenous, allowing us a glimpse into the diversity of tooling or techniques used in scanning and opportunistic exploitation. While many actors may use the same exploit vector or payload, they may launch them from tools that support different HTTP features. These new tags may help the analyst determine if two IPs appear to be using the same tools.
For example, in Figure 3, we are able to determine with a high degree of confidence that the IP shown above is orchestrating a full-featured web browser (such as Puppeteer) to scan the internet. We see this because the IP exhibits browser-like behavior and attributes, including carrying a referer header, accepting cookies, and following redirects.
We hope these new tags offer our users greater insight into the tooling and libraries utilized by internet background noise-makers. Let us know what you think by sharing your feedback on the GreyNoise Community Slack channel (must have a GreyNoise account).
Imagine this scenario: You’re running a security operations center, and your team is processing a bunch of alerts coming out of Splunk Enterprise Security. As you add new detections and log sources, the volume of alerts begins to rise, your analysts start to get overwhelmed, and that familiar alert fatigue starts to kick in. Your security engineering team jumps in with yet another cycle of tuning to get the alert volumes back down to manageable levels. Then the cycle starts all over again...
Hurricane Labs lives this reality every day as a managed services provider that is 100% focused on Splunk and Phantom. The company manages these platforms for customers, providing 24x7 monitoring services supported by a team of Splunk ninjas to handle the heavy lifting.
Recently the Hurricane team found a way to leverage GreyNoise Intelligence data to identify the noise in Splunk and Phantom alert traffic, reducing the load on their analysts by 25%.
We had the good fortune to chat with Hurricane Labs Director of Managed Services, Steve McMaster, to learn how the company had done it.
STEVE MCMASTER: Sure - to set the stage, we manage Splunk and Phantom deployments for our customers, running the gamut from infrastructure management, to search and SPL creation, to security analysis and alerting, to rapid incident response. As part of these services, we provide 24x7 security monitoring, and I oversee the two teams that deliver this service. I’ve been with Hurricane for almost 14 years at this point - it's actually the only job I've ever had. I started here at age 17, right out of high school, and along the way, I've done a little bit of everything.
STEVE MCMASTER: We process a high volume of alerts on behalf of our customers, and as part of this traffic, we often see a lot of noisy alerts. This includes everything from known benign scanners (such as Shodan) to what we call "internet background noise," scanners that are constantly scanning the internet as a whole, looking for things to poke at.
The alert volumes we see are a constant ebb and flow, and we spend a lot of time tuning our customer’s environments to turn down the noise to a manageable level. But then, as we add new customers and more detections, the alert volumes start to creep back up. That’s when we see our analysts getting overwhelmed and feeling alert fatigue. It’s a normal cycle for our business, alert volumes go up, and then we need to dig in and tune our implementations to bring the volumes back down.
STEVE MCMASTER: We were starting a new cycle of tuning to get alert volumes to come back down when I stumbled on Andrew [Morris, GreyNoise founder]. I saw my boss and Andrew exchanging views on Twitter, and I thought, “Who is this guy, and why does the stuff he’s saying make so much sense?” So I took a look at the GreyNoise product.
I have to say, I’ve always been a big skeptic of threat intelligence as an industry because once enough people know about a piece of intelligence to publish it for general consumption, it’s already burned infrastructure. Yes, you might find some threats with it, but it's not worth the $150K per year that they charge for it.
But GreyNoise was different. I always refer to GreyNoise now as “anti-threat intelligence.” It’s specifically the opposite of traditional threat intelligence. Instead of saying, “pay attention to this,” GreyNoise says, “STOP paying attention to this; go spend your time on other things.”
So this approach fit into an argument I was having with our customers a lot at the time - my point was that the things that you’re detecting are not actionable. They’re not targeted at you; they’re not somebody trying to exploit you; they’re JUST scanning the internet. So you shouldn’t worry about them or spend time on them.
Shodan makes a really good example of this, because Shodan is scanning everybody and showing up in a lot of alerts. But this is not something YOU need to care about, Mr. Customer; therefore, it's not something WE need to care about as part of our monitoring service. The problem is that this is really hard to quantify. You can show people that alerts from Shodan should be ignored — that's easy, but trying to identify broader Internet background noise was a lot harder to do. To be able to say, “Okay, we've seen this thing across our 40 customers, so let’s ignore it,” that's not really enough scale to be able to make this conclusion definitively.
And then along came this guy who had a product that did exactly that. So GreyNoise let us expand our service in a way that customers kind of already expected from us. Now we could say, “Look, this is opportunistic, this is generalized, this is global, this is not targeted.” And we could say this definitively because of the scale that GreyNoise operates.
And it really just happened to fit at a time when that was a problem we were trying to tackle with our customers.
STEVE MCMASTER: We’re using GreyNoise in two ways - we use the data inside Splunk to eliminate alerts before they ever get to us, and then we do enrichment of alerts in Phantom once they reach us. We integrate the GreyNoise data into these environments using pre-built integrations that we initially developed, although we have turned these over to GreyNoise to maintain and extend for all their customers.
Our goal with these integrations is that if the IP address is in GreyNoise, then we eliminate it from alerting. GreyNoise actually returns 3 basic categories of “noise:”
The reality is that some customers are not totally comfortable with the accuracy of these classifications (at least at first), so for some customers, we still raise a low-priority alert so they can have a human look at it. I think that this comes down to trust --and based on OUR experience-- if GreyNoise is confident the IP address is a scanner, then we are happy to ignore it. I would say about two-thirds of our customers are there today.
I’m also really excited about something Andrew mentioned at the last Open Forum conference GreyNoise held, the new RIOT service. Instead of identifying internet scanner “noise,” RIOT looks at the flip side of this by identifying the “known good,” common business services that everyone uses, like Slack or Office365, or Google IP addresses. So now we can easily tell the difference between a legitimate service like a Microsoft update and a "not legitimate" service like a malware download.
STEVE MCMASTER: Sure, so when we use GreyNoise to filter noisy alerts out of Splunk, we use the GreyNoise-Splunk integration. We install that in our customer’s Splunk environment and add it to the search language for various detections. The logic is straightforward: if something in the search results matches GreyNoise, it gets excluded.
More specifically, we apply GreyNoise to any correlation search or detection inside of Splunk that we think is relevant. The big ones are IDS events and Splunk’s vulnerability scanner detection rules; those are the main ones that we use it for.
For Phantom, on the other hand, we use GreyNoise as an enrichment. The way our monitoring service works, we bring all of our customers’ alerts into a single Phantom instance, and we have the GreyNoise-Phantom integration installed. For our analysts looking at the alerts, one of the first things they do is look at the GreyNoise data. If the verdict is “noise,” then we know we don't need to do a lot more digging beyond that. This ends up saving us a lot of time because rather than investigating whether this is a targeted attack and figuring out whether anything was exploited, we can just short circuit the process, note it as a scanner, and send it over. Today we’re doing this as a manual process, but it's on our list to automate this into our incoming Phantom playbooks.
STEVE MCMASTER: When I first told Andrew that we'd be interested in subscribing, I told him I had no concept of how much something like this would be worth. I didn’t know if we were going to turn this on and see matches with 10 alerts per day across our customers or 100. But the impact on alerts is really the only thing I had to help quantify the value of GreyNoise.
So Andrew gave us a two week trial, and I added it to our triage tool (this was before we stood up Phantom). And I just counted up how many alerts over a week would have been something we could totally ignore with GreyNoise versus what we would not have been able to. We were somewhere in the vicinity of saving the equivalent of one to one and a half analysts per day, out of 22 total analysts at the time, based on the alerts that we could safely eliminate with GreyNoise.
Today, after implementation and with more customers in hand, GreyNoise helps my teams eliminate background noise and focus on the most actionable and relevant alerts for our customers. Rather than presenting our analysts with even more data to investigate, GreyNoise has allowed us to reduce the volume of alerts that are triggered by 25%, which makes for a happier and more effective SOC team.
And for us as an MSSP, this is even more significant than it might be for an enterprise. When you’re in a normal enterprise business, you can make a decision to spend money on a person or spend money on a product that eliminates alerts--you kind of have to pick your poison. But for us, the calculus is a bit different. When we invest in a person, that analyst can do, say, 20 alerts per day. But if we invest in a product, that product can triage a certain number of alerts at every one of our customers. And for every new customer, it can repeat that work. So even if GreyNoise could only eliminate 8 alerts per day across 40 different customers, that’s 320 alerts. As we add more customers, GreyNoise scales in a way a person wouldn’t.
On September 21, 2021, VMWare published an advisory for several vulnerabilities. This included, most notably, CVE-2021-22005, which affects their vCenter Server product. This vulnerability is an arbitrary file upload vulnerability that can lead to remote code execution (RCE) via upload of a specially crafted file. This works regardless of the configuration settings of vCenter Server.
Due to the severity of this vulnerability, VMWare published workaround instructions detailing how to manually or automatically patch the affected products. The automated patching script (available in the right-hand panel in the link above) includes logic to validate if your product is vulnerable to CVE-2021-22005, as well as confirm the patch has worked as expected.
As of September 23, 2021, there is no known publicly available proof-of-concept (PoC) code for the CVE that enables arbitrary file upload or RCE. However, GreyNoise is observing a significant number of checks for vulnerable instances of vCenter Server based off of the automated patching script provided by VMWare, most of these egressing via Tor.
The following tags have been released to enable monitoring of relevant activity:
Editor's Note: If either of these tags return "no results," this means that we have not observed any recent activity. You can be notified if this changes by using our Alerts feature.
Atlassian Confluence Server OGNL Injection Attempt [Intention: Malicious]
Atlassian Confluence Server OGNL Injection Vuln Check [Intention: Unknown]
Oracle WebLogic RCE CVE-2021-2109 [Intention: Malicious]
Seagate BlackArmor RCE Attempt [Intention: Malicious]
ASUS GT-AC2900 Auth Bypass Attempt [Intention: Malicious]
Apache SkyWalking GraphQL SQL Injection [Intention: Malicious]
Carries HTTP Referer [Intention: Unknown]
Stores HTTP Cookies [Intention: Unknown]
Follows HTTP Redirects [Intention: Unknown]
RSYNC Crawler [Intention: Unknown]
University of Michigan [Intention: Benign]
As part of our process, our research team continues to clean up and improve on existing tags as new information or better processes are introduced.
ADB Check [Intention: Unknown]
ADB Attempt [Intention: Malicious]
EDITORS NOTE: This blog post has been updated as of Sep. 2 to reflect edits to the Atlassian Confluence Server OGNL Injection tags.
Tag: Exchange ProxyShell Vuln Attempt [Intention: Malicious]
Tag: Exchange ProxyShell Vuln Check [Intention: Unknown]
Tag: Javascript Enabled [Intention: Unknown]
Tag: Aerospike RCE Attempt [Intention: Malicious]
Tag: Docker API Container Creation Attempt [Intention: Malicious]
Tag: Buffalo Router RCE Check [Intention: Unknown]
Tag: Buffalo Router RCE Attempt [Intention: Malicious]
Tag: FirebirdSQL Crawler [Intention: Unknown]
Tag: Ruijie EG Command Injection Attempt [Intention: Malicious]
As part of our process, our research team continues to clean up and improve on existing tags as new information or better processes are introduced.
Tag: X Server Connection Attempt [Intention: Malicious]
Tag: ADB Worm [Intention: Malicious]
During BlackHat 2021, security researcher Orange Tsai demonstrated a proof-of-concept exploit for Microsoft Exchange vulnerabilities, including a Pre-auth Path Confusion leading to Access-Control List (ACL) bypass (tracked as CVE-2021-34473, also called ProxyShell). Since Tsai’s talk, multiple researchers have published write-ups about the vulnerabilities [1, 2]. GreyNoise had not observed any mass scanning activity until Aug. 9, and has seen a significant uptick in scanning as of Thursday, Aug. 12. GreyNoise has created two tags to track activity related to these vulnerabilities.
Exchange ProxyShell Vuln Check: The vulnerability check for CVE-2021-34473 has several public variations. These include checking for access to /mapi/nspi which results in exposure of potentially sensitive information such as Version, User, UPN, SID, and Organization. Out of caution, GreyNoise tags this as malicious intent despite being a Vuln Check. [View In GreyNoise]
Exchange ProxyShell Vuln Attempt: Active attempts that leverage and chain the Pre-Auth Path Confusion for further exploitation through Elevation of Privilege on Exchange PowerShell Backend (CVE-2021-34523) or Post-auth Arbitrary-File-Write leading to remote code execution (CVE-2021-31207) are included in this tag. [View In GreyNoise]
Editor's Note: If either of these tags, or any tags for that matter, return "no results," this means that we have not observed any recent activity. You can be notified if this changes by using our Alerts feature.
CVE-2009-0545, CVE-2019-12725, CVE-2020-29390
Tag: Zeroshell RCE Attempt [Intention: Malicious]
Tag: Cisco Smart Install RCE Attempt [Intention: Malicious]
CVE-2021-35464
Tag: ForgeRock OpenAM Pre-Auth RCE Vuln Check [Intention: Unknown]
CVE-2021-35464
Tag: ForgeRock OpenAM Pre-Auth RCE Attempt [Intention: Malicious]
CVE-2021-33544 to CVE-2021-33544 (11 CVEs)
Tag: UDP Technology IP Camera Attempt [Intention: Malicious]
CVE-2021-33544, CVE-2021-33548, CVE-2021-33550 to CVE-2021-33554
Tag: UDP Technology IP Camera Check [Intention: Unknown]
CVE-2017-12149
Tag: Jboss Application Server RCE Attempt [Intention: Malicious]
CVE-2021-30497
Tag: Ivanti Avalanche Path Traversal [Intention: Malicious]
Tag: Double URL Encoding [Intention: Malicious]
Tag: Apache OFBiz Deserialization RCE [Intention: Malicious]
These tags have been removed because they no longer exist, scan, and/or can no longer be accurately identified
Multiple RDP tags have been deprecated in favor of RDP Crawler, which more accurately accounts for much of the behavior we see. We are currently working to create more accurate and narrowly scoped tags for RDP scanning and exploitation.
The RDP Bruteforcer tag was created around the same time as BlueKeep and aggressively assigned `malicious` intent to basic RDP connection attempts. After re-evaluating this, we feel this was incorrect and have taken actions to improve our RDP tags in general.
As part of our process, our research team continues to clean up and improve on existing tags as new information or better processes are introduced.
Tag: Cisco Smart Install Endpoint Scanner [Intention: Unknown]
Tag: Linksys E-Series TheMoon Worm [Intention: Malicious]
Anomali: Now supports RIOT and the Community API.
CVE-2020-36289
Tag: Jira User Enumeration Attempt [Intention: Unknown]
CVE-2021-1497, CVE-2021-1498
Tag: Cisco HyperFlex HX RCE Attempt [Intention: Malicious]
CVE-2021-1497, CVE-2021-1498
Tag: Cisco HyperFlex HX RCE Vuln Check [Intention: Unknown]
CVE-2020-35846, CVE-2020-35847, CVE-2020-35848
Cockpit CMS Command Injection [Intention: Malicious]
These tags have been removed because they no longer exist, scan, and/or can no longer be accurately identified
Please update your search term or select a different category and try again.