AWS re:Invent 2025 - Protecting Your Infrastructure with Amazon Threat Intelligence (SEC311)

🦄 Making great presentations more accessible.
This project aims to enhances multilingual accessibility and discoverability while maintaining the integrity of original content. Detailed transcriptions and keyframes preserve the nuances and technical insights that make each session compelling.

Overview

📖 AWS re:Invent 2025 - Protecting Your Infrastructure with Amazon Threat Intelligence (SEC311)

In this video, Marshall Jones and Mike Artz from AWS Security explain how AWS protects customer infrastructure using threat intelligence at massive scale. They detail AWS's visibility into 60% of daily internet traffic (2.6 billion IPs) and processing 6 billion security telemetry events per second through sources like VPC flow logs, DNS queries, API logs, and MadPot honeypots. The presentation covers three threat categories: network reconnaissance (blocking 20,000 malicious IPs per minute), compromised credentials (affecting two-thirds of security incidents), and malware detection. They demonstrate how AWS threat intelligence feeds into native services like GuardDuty, AWS WAF, Network Firewall, Route 53 DNS Firewall, and Inspector, enabling customers to leverage AWS's global threat visibility for local workload protection through managed rule groups like Active Threat Defense and Account Takeover Prevention without operational overhead.

; This article is entirely auto-generated while preserving the original presentation content as much as possible. Please note that there may be typos or inaccuracies.

Main Part

Introduction: Protecting Your Infrastructure with Amazon Threat Intelligence

Welcome everybody. Those of you who have braved it out here this morning, welcome to Protecting Your Infrastructure with Amazon Threat Intelligence. My name is Marshall Jones. I'm a Security SA here at AWS. I focus day to day on our detection and response services, our native services that customers can operationalize and scale, and then feeding back into how we're going to evolve those over time. I'm here with Michael. Let him introduce himself.

Hey everyone, I'm Mike Artz. I work with AWS Security as a Principal Security Engineer, and I focus on our active defense programs, which is really about making AWS the safest place for builders transparently without you having to do anything. We'll discuss a little bit more about that throughout this presentation.

So hopefully if you're here, you're interested in threat intelligence. If you haven't seen it, I want to call out that we've posted a number of different blogs on threat intelligence lately about what AWS does discovering different threat actors out there and how we take them down. If you have not seen that, definitely worth Googling AWS threat intelligence and checking that out. What we want to do in this talk is go a little bit deeper on some of the stuff that's going on behind the scenes that Michael's team is doing.

How many folks here consider themselves threat intel experts? Raise your hands. Somebody raised their hand, I'm sure. That's good. You're going to learn something then. How many folks understand what AWS does on the threat intelligence page? Has anybody seen those blogs that I mentioned a minute ago? A couple of people. And then how many folks understand how AWS threat intel goes into native AWS security services? Anyone on that one? You're all going to learn a lot today then.

What we want to get out of this talk is to learn some stuff. This is a learning conference where you're going to learn about how AWS does threat intelligence at scale, how we think about threat intelligence, and how we go about collecting and tuning that. But ultimately we want you to take something away from this that you can go use to improve the security at your organization. We want to focus on some of the ways that you can use AWS threat intelligence in a manner that is not overwhelming using our native services and get the most out of that to protect what's specific to your application.

With that said, what we're going to do is Michael is going to go through some of the AWS scale and scope and how we are uniquely positioned to collect data and analyze these different threats that are out there. We'll go into how we do this collection and then we're going to go into some examples. You're going to hear us talk about global and local. What is AWS doing for our customers as a whole just for being an AWS customer, and then we're going to focus on some of these examples and what you can do for your specific applications to protect your specific workloads and even enhance that even more with some of that great threat intelligence that we're collecting.

AWS Scale and Scope: Visibility Across 60% of the Internet

With that said, I'm going to pass it over to Michael. Thanks, Marshall. So I'd like to start with the scope aspect in two different pieces: the visibility that we have as AWS wide and our global visibility, and what visibility you have as a customer into these different threats and the protections that we apply automatically AWS wide and the ones that you can configure and apply within your own workloads.

This wouldn't be a good security talk if we didn't show the shared responsibility model, but this also parallels our ideas of scope and protections. AWS operates the networks, the hardware, the services, and the software, and that gives us a broad global visibility into what is actually happening across the internet. You have deep insight into your own workloads and your own risk tolerances and can configure those deeply for you.

I'll start with a statistic on AWS scope. Every day, AWS interacts with about 60 percent of the entire internet. My definition of entire internet here is that there are about 4 billion IPv4 addresses out there, and every day AWS sees about 2.6 billion of those IP addresses with some part of AWS. That's a massive global vantage point that we can see. This breaks down in a couple of different ways, and this is how I like to think about AWS and how it breaks down internally.

If you didn't realize it, AWS builds on top of AWS. It's kind of AWS all the way down. The AWS services are built just like you would build web services, and they comprise a class of things that operates on top of AWS with their API. We have our deception technologies, like you might have heard of our MadPot honeypots or our dark space monitoring, that are trying to elicit malicious communications and directly find those threats.

We have all of the Amazon business lines and AWS business lines also operating on top of AWS, and then we have all of you, our customers, with your unique workloads also operating on top of AWS. And then out in front, we have the mediator between AWS and the rest of the world, our networking stack. And this is where we get a lot of that global visibility, that 60% of the internet everyday visibility from that networking stack.

And so I want to break down each of these pieces and some of the telemetry that we're seeing at each of these places, and how we're looking for threats within those. At that networking stack, we're looking at network flow largely, so interactions between IP to IP port information. And because as AWS we need to know who's on the other end of that IP within AWS, we also know the instance and the account that that IP maps to internally.

Also in the networking layer we can see DNS. We have visibility into DNS, and that's about 34 million requests per second. I should note the network flow of 4.8 billion flows per second. It's a massive incoming data set. Every second we get 4.8 billion new flows, DNS at about 34 million requests per second, and that gives us insight into the domains and the resolved IPs. You'll see how these play out in some of our threats that we're analyzing later.

We have visibility into the AWS API logs, and that's at about 100 million requests per second. And that gives us insight into the HTTP layer, a slightly higher layer, sort of what APIs are being called, and specifically which we'll call out later, some of the authentication that's happening in those layers. And then Amazon and AWS operate our own host telemetry agents, so we collect telemetry from all of the hosts that are owned by Amazon. That's at about a billion events per second. And those are things like every time a process starts or stops, we collect that information about what the process is and what it's doing.

And then we get deep threat intel information from our deception technologies, from our honeypot, and that's about 15,000 interactions per second worldwide. And in that case, we get full content because there's no good reason to interact with a honeypot other than if you're a malicious actor, and so we do collect all of that information. And so if you are keeping track, that's about 6 billion security telemetry events per second.

Data Platform Architecture and Customer Visibility Through AWS Services

Now, some of those are automatically usable, like our interactions with the honeypots, like I mentioned, almost all of that is malicious, and so we can mine that immediately for all of that threat intelligence. But others, like the flow records, like the API calls are almost entirely legitimate. So in those spaces, we really need to go hunting for those threats within that massive amount of data. And to do that, we're looking for patterns within those flow records, and we need a data platform that can handle it.

And so I'll show the one architecture diagram that I'll show on this, and I'll show it for two reasons. One, this is our data platform. And we need three pieces of information, or three capabilities from our data platform. First, which is kind of that top flow, we need the ability to do a low latency and high-speed stream filtering of all that data as it's coming in to do real-time threat detection on it. And this flow structures, ingests all of that information, structures and enriches it, and allows us to apply rules to it to immediately detect threats or identify patterns of behavior in real time as it's streaming.

But we can't do everything as a stream, so that's where that second capability of our data platform comes in to play, and that's that next box down where we take all of those 6 billion events per second, all of that visibility, and we optimize it for query, we store it in S3 as parquet. And that allows us a couple of different things. That allows us to go back in time from after we see an event happen and see what happened around the time of that event, what processes we're executing around the time, what other network flows were happening around the time that we detected something.

It allows us to historically look and develop new threat detections, and provide investigation capability for our investigators and our threat analysts. And then finally, because even at AWS we can't store all of that data forever, we selectively summarize it, and we keep the interesting bits from the data, but lose things like time resolution, so we'll summarize it by hour or by day, and those summaries we do keep long term for multiple years. And that allows us to go far back in time and still answer relevant security questions from our data.

So that was AWS's visibility. Now, what is your visibility as a customer? Well, you have a very analogous set of visibility telemetry, in the form of VPC flow logs, Route 53 DNS query logs, and CloudTrail events that parallels those other pieces that we're actually analyzing on the global scale.

You can absolutely control these and gather them and analyze them yourself, or you can turn on GuardDuty to do that for you. As Marshall will show later, GuardDuty will benefit from the visibility that we gain at the AWS scale to enhance the analytics at the local scale. You also have deep insight into your own workloads and your own application logs, your own host logs that you can collect and get deeper insights. More importantly, you have insight into the risk tolerance in your particular business and what you can accept and cannot accept for your business.

To summarize visibility, we have your AWS-wide or global visibility, which is this massive scale that's seeing about 60% of the internet every day. However, it is limited in how deep it goes. It is very surface level because we do not look at your data. We only look at the data that we need to operate our networks and operate our hosts. So we cannot see deep into the data like you can with your local visibility.

AWS-Wide Protections and Customer-Configurable Security Controls

Now we want to look at the protections and what we can actually do. I want to caveat this because we're talking about what we can do as AWS on your behalf. These are capabilities that we have, but it is not a hammer that we wield blindly. We make sure that we do a risk analysis before we take any of these actions to make sure that they're safe to apply for all of AWS and your workloads. When we're operating at AWS-wide scale, for example, when we're blocking IPs at the networking layer, that blocks those IPs from interacting with any part of AWS. We have to be both sure that it's malicious and that blocking that IP will not impact any customer workload.

Another mitigation that we have when we detect abuse is that we can selectively throttle at specific AWS APIs. For example, we used this previously to help with an S3 ransomware attack where we could block the attackers using compromised credentials from being able to execute S3 ransomware techniques by blocking at the S3 API. In cases of abuse, our trust and safety team does have the ability to isolate abusive EC2 instances where we can essentially cut them off the network and say that in the case they are performing a DDoS, which we'll get into later, they are not allowed to behave on the internet anymore. We take these things very seriously and make sure that it's safe to do for all customers and for your workloads.

Finally, probably our easiest mitigation is to actually notify you. We will send emails through our trust and safety and fraud departments, and you can get notifications when you enable GuardDuty through the same detections that GuardDuty benefits from what we're doing here.

That was the AWS-wide protections, but in your space, the sky is the limit. You can configure things like WAF, DNS Firewall, and Marshall will touch on a lot of these and how you can benefit from the visibility by configuring these yourself for your own business. Now that we've set the stage of the visibility and the mitigations that we have, we'll talk about threat intelligence specifically. I'll give a short introduction to threat intelligence and the different types of threat intelligence.

Understanding Threat Intelligence: From Strategic to Technical IOCs

At one end, we have strategic threat intelligence, which is that high-level view. If you've ever read the various yearly breach reports that various providers put out, they say here are overall trends that we see in threats this year, here are the overall motivations and attack trends. As we get more specific, we're looking at tactical threat intelligence. If you've heard of the MITRE ATT&CK Matrix, this is really trying to categorize what types of things an attacker does when they're actually executing an attack, like initial access, persistence, or detection evasion. These are generally termed TTPs, tactics, techniques, and procedures.

Going even more specific, we have a whole class of operational threat intelligence, which consists of specific campaigns and specific actors that are executing a specific mission at the time. This is usually very tied up with attribution. We're looking for who is doing it as well as exactly what they're doing and what tools they're using.

Finally, what we'll focus on for most of this talk is technical threat intelligence. These are the specific indicators like knowing that this attacker is using a particular IP as command and control or a particular DNS domain name to run their attacks. We focus on these because they are immediately actionable.

We can collect them with our visibility, we have the right visibility into them, and then we can actually make use of them immediately by blocking or otherwise isolating these sorts of IOCs. Now it's important to note that all of this threat intelligence has a shelf life. Attackers are advancing all the time, as quickly as we are. It's really an arms race. On the strategic end, the shelf life can be months, maybe even years. These are the general trends. You might have heard a lot about the AI trends in attacks that are coming out. These sorts of things have a shelf life of months, whereas on the technical end, those specific IPs or specific DNS domain names can have a shelf life of minutes. The attackers can rapidly cycle through their infrastructure to try and confuse detections, so we need to keep up with that and we need to be able to detect and respond to these things within a very short amount of time, keeping that threat intelligence always fresh.

The mental model that we use at AWS that I like to think of is the pool model. We have this pool of threat intelligence, which is all the threat intelligence from across AWS and Amazon that goes into one place, and it's constantly getting refreshed by our producers. One of those producers is our deception technologies like our Madpot honeypots and our dark space monitoring. These are things that are put out there to look vulnerable to illicit malicious behavior or look for scans that shouldn't be hitting those. There's really nothing registered to those for dark space monitoring, or there's no DNS name on the Madpot fleets. They're really just hidden corners of the Internet that if you happen to stumble upon them, which botnets and malware and various threats often do when they're doing broad scale scanning, we collect more information from.

Those are contributing all those technical IOCs to our threat intelligence pool. Another class of things is we have a whole bunch of human analysts that are looking primarily for operational threat intelligence like tracking specific actors and campaigns. They're also contributing the threat intelligence that comes out of those reports to our pool of threat intelligence. We have our threat analysis and detection folks who are analyzing all of that security telemetry and picking out those threat needles from the haystack. Every one of those detections that comes out of there goes into that same threat intelligence pool, and this is constantly being refreshed. All these teams are also consuming from the pool.

As our deception technologies improve, all of a sudden our detection technologies improve as well, because we can detect more threats, and that provides more information to our threat analysts to find new threats and track actors and campaigns. We don't just put everything into a pool; we also use it. Like we mentioned earlier, we use that global Amazon-wide scale to perform a risk assessment and say, is this IP safe to mitigate? Is this DNS domain safe to mitigate? We put it through a very rigorous risk assessment to determine first, are we sure that it's malicious, and second, is it actually safe for your workloads. If it is, we actually place that mitigation. This is what we do at AWS scale to automatically protect all of AWS without you even knowing or paying for it. Just by being on AWS, you get the benefit of all of this work.

Network Reconnaissance and Probing: Detecting Malicious Scanners at Scale

That same threat intelligence goes to all of the AWS security services like WAF, GuardDuty, and Network Firewall, and you can benefit from all this work that we're doing and this global visibility locally within your own account by configuring these services. We'll spend the rest of the talk talking about three different threat categories, and I'll start by talking about what we're doing as AWS and then I'll hand it off to Marshall for each of these, and he'll talk about how you can configure those services in your own account to actually utilize this threat intelligence. The first one I want to talk about is probably the earliest in the attacker kill chain, which is network reconnaissance and probing, where attackers are trying to scan broad swaths of the Internet to see what's out there and is it worth going after.

They generally start by sending packets to a whole bunch of different IPs. Because Amazon owns a large number of those IPs, at some point in time, those packets are going to come to Amazon's IP space. I mentioned before that we have this networking stack that's in the middle that knows how to map an IP at any time to the instance or account that's behind it or resource that's behind it. This is very dynamic and changes all the time, and a large number of these aren't mapped. If those packets hit our networking stack and it's not mapped, they just get dropped. But other ones do get mapped, and some get mapped into our AWS services, some get mapped into our deception technologies, some get mapped into Amazon.com, your favorite bookstore, and some get mapped to your workloads as well and your resources.

These IPs are very dynamic. You can request new IPs and change the mapping at any time. What we're looking for at AWS is behavior where a single IP address is sending packets not just to a large number of IPs, but those IPs map to a large number of distinct accounts, a large number of distinct resources, and a large number of distinct instances. When we see this pattern, we call it traffic analysis or behavioral monitoring, and we can immediately label it as likely malicious—a broad-scale scanner looking for what's available on the Internet. The threat intelligence we can extract from that is the scanner's IP address because that's our visibility. We can also look at what they're actually scanning for.

In this case, we're largely looking at VPC flow network flow logs , so we examine the ports they're actually scanning for. These are largely things like web ports such as 80 and 443. However, there are services on other ports, and when we see broad-scale scanning for other ports, that also goes into our threat intelligence pool and provides insight to our analysts. We ask: is there something new that we don't know about? Is this particular service vulnerable? Has a new zero-day been released? We can further refine that and find more information, and we do that in a number of different ways. That's how we keep that pool consuming from that pool as a global flywheel to derive more threat intelligence from this basic traffic analysis.

When one of those scans hits our deception technologies , it's almost immediately suspicious because there's no good reason to interact with our honeypot or our dark space. We can immediately classify that host as malicious. When that host follows up with something like a probe asking if that host is vulnerable or even sending an exploit, we can double down on that assurance that it's very likely a malicious host doing this. We collect more threat intelligence because our honeypot captures the full content of all those interactions. We can look at things like the TLS fingerprints to uniquely identify the host's TLS stack, the HTTP user agents and headers, and the full content of the exploit and anything that was sent. We put that into our threat intelligence pool and do automatic mining of that data as well, feeding it back into our detections and back to our threat analysts.

So what do we do when we see these sorts of things? We block them. We put them through a risk mitigation to make sure that it's safe to block. For example, we can't just block all proxy or anonymization networks like Tor because there is valid use. Many customers use those networks to interact with their AWS resources, so we can't just blindly block them. But in those cases that pass our risk assessment, we can. When those scanners hit our networking stack, we tell them we don't know who that IP address is and we drop their packets immediately. This provides a kind of global firewall around all of AWS so that you are safer just by operating on AWS. We see about a 73% reduction in attacks for operating on AWS versus operating outside of AWS. We see that because we deploy our deception technologies both inside and outside of AWS and we measure the differences. We see about a 73% reduction.

Customer Defense Against Network Threats: AWS Network Firewall and Active Threat Defense

At any point in time, which is widely variable, we're blocking about 20,000 IPs that we refresh every minute as the attackers are changing their use of those IPs. Now I'll hand it off to Marshall who will talk about how you can configure this for your workloads. So one of the things that I want to start with, given all the great stuff that Michael just went through, is that a lot of the questions I get from customers is: okay, you guys have all this great visibility and this threat intelligence. How do I take advantage of that? Can you give me your threat intelligence? Now, as Michael pointed out, that is constantly being refreshed and there's a lot of sophistication behind the scenes to make sure that an IP is still a malicious IP and hasn't been recycled and is now on some legitimate application. So how do we give that to customers so that they can take the most advantage of that without creating false positives and creating unnecessary work on the customer's behalf?

Over time we have continued to feed these into our native services, and I'll go through some of these examples. That's really how we see the best way to give our customers access to that threat intelligence while still being able to help keep it refreshed and make sure that it's being utilized and not creating undue hardships for customers. So one of the first ways to help with network reconnaissance is to use AWS Network Firewall. If you're not too familiar with AWS Network Firewall, this is a stateful managed network firewall intrusion detection prevention service.

With many of these AWS services, you'll see the managed aspect of them. For example, with Network Firewall, this can support hundreds of thousands of connections up to 100 gigabits per second of throughput, and you never have to manage the underlying infrastructure to take advantage of that capability.

When it comes to the flexible rules engine, you can create your own stateful and stateless rules that are completely customizable for you as the customer. You can also take advantage of AWS managed rules and, as of a couple of days ago, partner rules as well that you can subscribe to through AWS Marketplace and utilize.

One of the specific rules I want to talk about is the Active Threat Defense rule. This is an AWS managed rule that can help block traffic associated with malware staging URLs, botnet command and control servers, and crypto mining pools. This threat intelligence is being pulled from deception technologies like MadPot and from the work across the different threat intelligence teams at AWS that feed into this managed rule group. We continually tune and configure it so that customers can take advantage of this through Network Firewall for both inbound and outbound traffic, which we'll discuss more about outbound blocking in a moment.

We want to jump into a couple of examples of what this would look like for a customer. If you haven't used Network Firewall before, there are a number of different ways to look at logs. I've pulled some basic examples of what this might look like. If you're using the Active Threat Defense rule group and you are looking at a log to see what happened, you might focus on a few different things.

The first thing is what is the source IP that was actually communicating. What was the threat associated with this? You can see the threat name, which in this example is suspicious staging malware at an IP address. We can see the action of what happened here. With Network Firewall, you can alert, allow, or block, and this gives you that information of what really happened. If you look above, you can see the signature that fired on this as well.

For good measure, we also looked at the community score on VirusTotal just to evaluate AWS threat intelligence with a repository that many folks validate different resources against to see if they're malicious. As you can see, it was also flagged as malicious there.

AWS WAF Managed Rules: IP Reputation Lists and Known Bad Inputs Protection

The next service I want to discuss is AWS Web Application Firewall, or AWS WAF. If you're not familiar, it's a layer 7 web application firewall that provides protection against DDoS, OWASP top 10 vulnerabilities, and different CVE vulnerability exploitation attempts against web applications. Once again, there's low operational overhead. You essentially just associate it with an API Gateway, an Application Load Balancer, or CloudFront, and we do the scaling. It doesn't add any latency to your application and scales as high as your application traffic can go.

There is once again a combination of the ability to create your own rules, use AWS managed rules, and also use different partner rules that you can subscribe to through the marketplace. This is a great place to feed threat intelligence so we can give customers the ability to block more things that are specific to their application.

This is not an exhaustive list of all the WAF rule groups or the rule groups that you should use. We have many different publications out there on example rule group ordering and different things you can do with AWS WAF, so I definitely encourage you to look at that. However, I want to call out a few of them that use these threat intelligence sources that I think are definitely table stakes for many customers.

The first one is the Amazon IP Reputation List. The IP Reputation List is what we call a rule group, and at the bottom, the three different boxes that say "choose rule" and "override" are the individual rule groups. These include the Managed IP Reputation List, Reconnaissance List, and Managed IP DDoS List. You have the ability to configure each one of these individual rules and say, for example, I want to block for this, I want to count for this to see what would be blocked, and so on.

But this is how we're bringing some of that IP reputation directly into a managed rule. Once again, like I described with network firewall, we continually tune behind the scenes to make sure that these are actually malicious IPs, they're still malicious, and we're blocking only malicious traffic and not legitimate traffic. The second one that I want to call out is the anonymous IP list. This rule group contains rules to block requests from services that permit obfuscation or viewer identity. Think of some of the examples that Michael gave earlier like Tor, VPNs, proxies, and web hosting providers.

If you look at what we might want to block in some of these things, for example, your application doesn't need to communicate with Tor, so let's just take care of that right off the table. Are you running a consumer application? Does somebody need to connect from a different hosting provider? If it's a consumer application, probably not. So blocking that brings it straight off the table, you're reducing attack surface and reducing potential risk for access to a potential vulnerability in an environment or something that an actor might try to exploit. Anonymous IP is definitely something to look into. There's also great things like geo-blocking rules that folks should look into as well.

Another one I want to call out is the known bad inputs rule group. This contains rules that block request patterns associated with the exploitation or discovery of vulnerabilities. A lot of what we talked about in the technical threat intelligence space so far involves IPs, domains, file hashes, and malware things that we'll talk about in a bit. But what we learned through Michael's team and a number of different teams is some of the strategies that folks are using to try and exploit environments. I'm going to use everyone's favorite security example of the last few years, Log4j.

What we saw during that time were the different techniques and tactics that people were using. We took that information and put it back into a WAF rule so that folks could block traffic associated with those types of exploit attempts. This isn't specific to IPs or a specific domain of some actor campaign that we know is part of that. Those might have been blocked from the IP reputation list. But say, for example, there's a new IP that came online that just hasn't made it to that reputation list. This can give you more coverage based on the techniques that we're seeing.

Although a lot of the threat intelligence is IPs and domains, we can also take what we've learned there and put that back into other rules like this known bad inputs rule group. If we look at an example of this, hopefully folks have seen this before. This is an AWS WAF. They have built-in CloudWatch log insights where you can analyze logs associated with these rule groups and these rules that are firing. If we look at this example, we can see that we have the known bad inputs rule group with actual different log files associated with this.

If we look into one of these log files, we can see some of the information associated with what happened through this web request. One thing we can see is the action is that it's blocked. A lot of folks will build different dashboarding and things to understand blocks or counts, or maybe while you're operationalizing AWS WAF, if you want to understand what all is happening before you actually flip this to block, you put it in count mode. But this specific example is blocked. We can see the HTTP request arguments, and if you're familiar with Log4j, the JNDI lookup associated with that is visible. We can see the host that is involved here. This is an ALB that I set up.

We can see the rule group, which is the known bad inputs rule group, and then the specific rules. If you remember back to the slide where we had all those rules underneath this rule group, this is the specific rule that fired, the one that's associated with this query string. One other thing I want to call out is more of a detective lens in this space. WAF and network firewall are preventative controls. Inspector is a vulnerability management solution through AWS. It's a little bit different than a traditional vulnerability scanner where you set it to run at different times. This is based on a continuous method. So when you turn on Inspector, it can look at different resources like EC2 instances, images in ECR, and Lambda functions.

You can also put this into different SaaS-based scanning functions as well as CI/CD pipelines. The way it works is it does a full scan the first time and then it has an inventory of what software exists and what vulnerabilities exist on that host. When a new vulnerability gets introduced associated with a package or an OS that you're using, it checks to see if that exists. If something changes on a resource, it does an incremental scan to see what has changed and if any new vulnerabilities exist or old vulnerabilities don't exist anymore.

One of the places that we feed vulnerability intelligence back in here is when I talk to customers about vulnerability management. I probably admit more often than I should that deciding what we need to remediate and the prioritization that we need to take when doing remediation is critical. Funneling some of this threat intelligence back into Inspector and understanding what's going on with vulnerabilities helps with that process. If you haven't seen Inspector before, there's a vulnerability database you can see in the left navigation pane towards the bottom. We once again stuck with the Log4j example and looked that up.

If you look in that vulnerability, this tells you what vulnerabilities Inspector has in its database. You can see the vulnerability intelligence from AWS and what are the different targets that we're seeing associated with this. When was the last exploit seen? Obviously in some of these it will be a little bit different and other information that we might have with a vulnerability, but this can help customers inform their decisions. Have we seen a public exploit? Have we not seen a public exploit? Do I need to go prioritize this now across my environment? This can definitely help with some of those prioritization decisions.

So to recap here for the network reconnaissance example, on a global scale AWS has a lot of different levers for blocking different things and feeding that threat intelligence pool. As a customer, this is not an exhaustive list, but you have a number of different things here like WAF, Network Firewall using those managed rule groups, and then Inspector to reduce your overall exposure.

Compromised Credentials: The Two-Thirds Problem and AWS Detection Methods

Now we'll switch topics and talk about the compromised credential threat. Just to tease why this is so important, our customer security incident response team helps customers who have a security incident. About two-thirds of their cases deal with compromised credentials where the initial access and the initial threat vector was compromised credentials. These credentials have two things in common generally. They're single factor and they are long-lived. For example, a username or password or a long-term AWS API key and secret key.

These days, there's almost no reason to use these long-term credentials. AWS has a number of ways that you can get away from those and migrate to short-term credentials such as IAM Roles Anywhere. If you're interested in doing that, I highly suggest migrating away from long-term credentials, especially if you're embedding them in any applications or hardware or anything that leaves your control, because those can be easily reverse engineered and attackers can use those to behave like rogue agents. So please come talk to us if you're still using long-term, single-factor credentials, and we can help you change.

When we say compromised credentials, what we're really meaning is leaked credentials, exposed credentials, credentials that have left your control. For this talk we'll primarily be talking about AWS keys, especially those long-term keys that some people call IKEA keys because they begin with the prefix AKIA or AKA versus some of the short-term credentials like ASIA keys that begin with ASIA if you were ever to look at the actual key ID.

These can get leaked in a variety of different ways. You can accidentally commit them to public source control. They can get accidentally bundled up into your application that's deployed to a web server and available on the internet. There's unauthorized access to internal hosts that can steal these keys. In a variety of different ways, what we're looking for with our visibility is how they're actually used by threat actors. We'll get back and zoom out again to that global view of what AWS has across all of the globe and look at what a threat actor does once they get one of these leaked credentials.

Well, the first thing they do is try and say, is it any good? They do that by calling an AWS API, essentially any AWS API, and they'll get an error message if that key is invalid, if it's been rotated, if it's been disabled, if its TTL has expired. But what we notice is attackers don't just do this once.

They have purchased generally a large number of keys, or otherwise gathered a large number of credentials. So they'll try it with the second one and say, is this valid? And then a third, and then a fourth. And back to that traffic analysis or behavioral analysis, we can see this when this happens across the globe, whatever region. And we can look for this pattern of a single IP address trying to authenticate with multiple different keys, and each of these keys is associated with an account, and so it comes from different accounts. This is very anomalous behavior for standard AWS interactions.

And so we can label that as malicious. That is a malicious attacker trying to validate a large number of keys. And we can get a bunch of pieces of threat intelligence: the IP addresses again, the TLS fingerprints, and the credentials themselves, which become very important because as we see other actors doing this, because attackers generally sell these sorts of dumps of credentials, we'll see multiple attackers using the same dumps or overlapping dumps of credentials. As soon as we see them trying to validate one of those credentials that has been previously compromised and put into our threat intelligence pool and brought back into our detections, we can immediately say you're bad and everything that you have is now been leaked, and we can notify all the customers who have those leaked credentials.

And we also see the AWS service APIs. Which takes us to the next step in the analysis that we do: we're looking at how they're actually using these compromised credentials once they validate that they work. And we'll see generally the most common thing to start with that an attacker starts with is the API GetCallerIdentity, which just tells you who owns this particular key, what account is behind this. But we also see them then try to do things like GetSentQuota from Simple Email Service to set up spam relays. We see them try to create accounts to set up corresponding payer-linked accounts that you might own, but that you don't know about but you're paying for to gain persistence. Or things like run instances for crypto mining or with malware pre-installed on it.

And so by analyzing these things that an attacker cares about, we get this idea of the high value AWS service APIs to an attacker, and we can tune our threat intelligence to look for specifically these things and to look for sets of these things that are anomalous. Generally, there's not a lot of teams that use Simple Email Service. You either use it or you don't, and generally you don't use it for a long time and then suddenly start using it. So looking at these anomalies in the traffic of what an attacker does helps us classify these attackers and these service APIs.

And so what do we do when we see this happen? Well, the only real mitigation against compromised credentials is to rotate or disable that credential, full stop. Everything else is just a band-aid. One of those band-aids that AWS can apply sometimes is there is a specific policy, and you can Google this, the AWS Compromise Key Quarantine Policy. And basically that's a policy that just disables a whole bunch of things that attackers generally like to do that can cause your spend to go up if they were able to do this, and otherwise compromise your network, prevent them from doing further persistence.

And so in certain cases, AWS can apply this to those credentials if we're absolutely sure that that has been leaked and is in the hands of an attacker. We can do that selective API service blocking for certain things, which is where we get to the S3 ransomware that I mentioned earlier, where we use blocking in S3 to prevent, plus the presence of a compromised credential, to prevent certain S3 operations from happening using that credential. But ultimately, our hammer is our customer notification. So we will notify you via email from our trust and safety department, from our fraud department, and if you configure GuardDuty, you will see the same information because it goes into that threat intelligence pool coming as part of a GuardDuty alert.

Protecting Against Credential Compromise: GuardDuty Attack Sequences and ATP Rule Groups

We're just really happy that we haven't dropped this yet. So we're looking at a local perspective or what customers can do. One of the top things that folks do is enable GuardDuty. So this is our threat detection and incident response service. It has a number of data sources that can be collected to look at what might be suspicious to your specific account. So the basic things are the VPC Flow Logs, DNS logs, and CloudTrail events, and we have a number of optional different data sources such as S3 data plane events, EKS audit logs, Aurora login events, Lambda network activity, and runtime activity for ECS, Fargate, EKS, and EC2 instances so we can see actual telemetry on the host. GuardDuty is widely used and protects millions of accounts. In Matt Garman's keynote yesterday, he mentioned that GuardDuty monitors some number of quadrillion events per month, which gives us excellent telemetry at the service level specific to customers' environments.

We can then roll this into more threat intelligence directly for GuardDuty to help customers. We accomplish this in a couple of different ways: creating findings through threat intelligence, using machine learning, and integrating with a number of different services so customers can respond to these findings.

If we look at an example of these findings, what we have here is an attack sequence finding. Attack sequence findings bring together a number of individual GuardDuty findings to provide a holistic picture of a security issue you might be experiencing. This one is specific to credential compromise. If you were to get a notification from trust and safety, that's obviously super helpful to get some of that information. GuardDuty can help with the more holistic picture of what all is happening here.

This might be a little bit hard to see, but you can see some of the different MITRE ATT&CK tactics, techniques, and procedures associated with this finding. You can see more specifics on what exactly is happening and the resource involved. Each individual signal is like an individual GuardDuty finding. If you had to put the pieces of these puzzles together, you would see there was an initial access type of finding, an impact type of finding, and a discovery type of finding. These are all associated with the same AWS resource and they all occurred within the same time frame. The attack sequence finding brings that information together so you can more quickly get to your response or remediation actions.

Another example I want to discuss is AWS WAF and the account takeover prevention rule group. This is not specific to AWS credentials. Up until this point in the credential example, we have been talking about AWS credentials. AWS WAF is a layer 7 firewall that you put in front of your custom applications. The ATP rule group specifically can look for anomalous login attempts and login attempts from stolen credentials on request inspection. We can also use this to look at the response to see if the login failed or was successful and what the pattern is. Did it fail multiple times in a row in rapid succession? This is us using threat intelligence and maintaining a stolen credential database so you can protect your specific custom application.

Although it is not an AWS credential compromise per se, this is still compromised credentials out there that might be specific to your application or being used to exploit your application. This is just another way that you can take advantage of the threat intelligence pool, and this time not specific to AWS but specific to your application. In this example, the global protections and quarantine policy obviously notify customers whenever we see any activity associated with these compromised credentials. Definitely, not only utilizing GuardDuty but operationalizing GuardDuty findings is super important. What I mean by operationalizing is that if you get a GuardDuty finding, what are you going to do? Do you have a playbook? Who do you contact? What are the mitigations you are going to put in place? How are you going to do your investigation? Those operationalizing aspects of the puzzle are super important. Then look into the ATP rule group if you are running a custom application that has different user names and passwords associated with it that you want to protect.

Malware Detection Through Deception Technologies and DDoS Traffic Analysis

The final threat that we are going to look at is malware, and we are going to start by looking at our interactions with our deception technologies with our honeypots. Recall this graph where generally folks are scanning the network looking for reconnaissance and then probing and exploiting. Our honeypots happily allow them to do all this and say yes, I am vulnerable, please exploit me, please drop malware, please drop other scripts, because that is what honeypots do. Generally, the next thing that happens after that exploit is a piece of software is dropped to then reach out and get a more complex piece of software. Sometimes this is straight up malware, sometimes it is just the next stage in the exploit chain, and sometimes it is pseudo benign software like crypto mining software that then gets put down and configured. But because it happened in our deception technologies and because it happened after an exploit, we can immediately classify that as highly suspicious and likely malicious.

After the payload gets downloaded, it generally reaches back out to get either command and control or exfiltrate information such as stolen credentials. In the case of Bitcoin mining, it connects to a Bitcoin mining pool and starts trying to get the attacker some money. Because all of this was sourced from our deception technologies, we can immediately classify all of that as malicious and collect the same information we did previously.

Now we can get that malware binary and put it through static and dynamic analysis. We actually detonate it safely within AWS to see what it does and have our analysts look at it and pick out information about the malware distribution sites, the malware C2 sites, the IPs, and URLs. We can block all of those and prevent all access to this sort of attacker infrastructure.

But what if the attacker doesn't hit our deception technologies? That's where we fall back to those traffic analysis patterns. We'll use an example here from DDoS malware. With DDoS malware, there's malware that all of a sudden changes its network pattern. Those hosts all of a sudden start sending a lot of data towards one victim host on the internet with the idea that they want that victim host to have a bad day. Usually this is a large amount of bandwidth or a large number of requests.

At the networking layer, we can see this. If you've ever worked on a networking team or looked at a bandwidth graph, this is where your graph gets very lumpy. You see massive spikes, and it's very easy to spot from a volumetric perspective where we're just looking at how many bytes and connections are sent between IPs. From this, we can identify that that person is likely having a bad day and use that as part of our threat intelligence for that victim IP. We use that to figure out who is everyone that's participating in that particular DDoS.

This is great and we can help mitigate this after the fact, but really we want to go back in time. We want to prevent the DDoS from even happening. To do that, we need to use that data platform I mentioned earlier to look at well, now that we've seen a DDoS and that's very easy to detect. Who was involved in that DDoS and who did they communicate with that might have told them to perform that DDoS? Generally right before a DDoS happens, all those same instances are reaching out or being contacted by a singular host, a command and control host or a small number of hosts.

That's exactly what we do. We look back in time and say just before the DDoS, who were you all contacting? Generally this is because it's a DDoS, it's distributed. There's a large number of instances in play in this and who did they all contact at the same time right before the DDoS happened? That allows us to identify that malware command and control and that malware C2 IP. Then we can block it. We do this in a large case because a lot of this malware infrastructure is either fairly static or fairly unique to malware or attackers.

We can run it through those risk mitigations and determine yes, it is safe to block. There's no legitimate use of these IPs, these DNS domain names, things like that. So we can block those malware command and control hosts and in some cases this completely neuters the malware and prevents it from actually working anymore. We can also block those distribution sites that we gained from to prevent hosts from even downloading the malware. Even though the host might have been exploited, we prevent that next stage in the kill chain to prevent the malware from being installed.

In the cases of hosts performing abusive behavior like DDoS, our trust and safety team can occasionally isolate those instances to wall them off from the network to prevent that future abusive behavior. Ultimately we will notify you that you have a compromised instance. From our standpoint, we will notify you via email, but if you enable these services, you can get those same insights for your account with much deeper data.

Customer Malware Defense: Route 53 DNS Firewall, GuardDuty Runtime Monitoring, and Key Takeaways

We've talked about the MITRE ATT&CK Matrix a couple times already. If we look at this, most of us are humans reading from the top down. We're understanding this is probably the sequence of activities. One thing that we wanted to point out that Michael discussed a minute ago was a lot of what happens at the beginning of this kind of attack kill chain. They get a basic exploit into the environment, something small, a little toehold, and then they call back out.

What we might think of as initial access and execution also has to do with some of these TTPs all the way at the bottom being command and control and exfiltration. So if we can stop that outbound communication at the beginning, we can also potentially stop attack progressions when they start before they even get malware and a foothold in the environment.

One of the best ways to do this is with Route 53 DNS Firewall. This works with the DNS resolver that's built into VPC, filtering domains. This is just like those other AWS firewall services that have a combination of custom rule groups or custom rules that you can create as well as Amazon managed rules. It integrates with Firewall Manager, which can help you deploy this across your organization very easily.

If we look at an example of DNS Firewall findings, you might see something pretty simple on an EC2 instance where you curl some domain. If we look at the corresponding log associated with this, we can see the query that happened there and then the firewall rule action that happened associated with that interaction. Stopping that outbound DNS communication at the start mitigates that attack progression early on.

Jumping back to Amazon GuardDuty that we talked about earlier, the threat detection capabilities include a number of different malware capabilities associated with GuardDuty. With our runtime monitoring, we can see things on the host. A couple days ago we launched AWS GuardDuty Malware Protection for AWS Backup, so you can look for malware associated with the backups of EC2 and S3. We also have malware protection for S3, which is often used for untrusted uploads before customers move files to a different point in their application. Those are different ways to take care of malware.

If we look at this example from runtime monitoring, you can see execution runtime malicious file executed, which is essentially the GuardDuty finding type. If we look at some more of this information, we can see the name of the process that was running, the executable path, and the SHA-256 hash gives us a lot more information there. We can also see the threat list, so this threat intelligence identified that the malware came from an AWS threat intelligence source in GuardDuty. We actually use a few different threat intelligence sources, a couple different partner sources along with the Amazon threat intelligence, but this is how we're identifying this malware.

Looking at one more GuardDuty example, we can see this one is associated with an object upload to S3. This is just a basic EICAR test file, so Michael and his team don't get mad at me for my personal account. We can see this malicious upload. We also have hooks into things like EventBridge, so you can do event-driven architectures where if this was a malicious file, you move it to a quarantine bucket, or if this was a clean file, you move it on to my application and keep rolling.

Protection from malware, blocking malware-related IPs, and isolating instances that Michael and his team accomplished across AWS at the customer-specific level, GuardDuty is another great thing here. I didn't touch on this, but Network Firewall is also a key piece of blocking traffic in and out associated with malware-related traffic. DNS Firewall is an AWS managed service that scales with your application, so there's no latency involved there.

To wrap up, just a couple of calls to action. It's important to understand AWS Threat Intelligence and what we're doing to protect all of our customers. What are the protections that you get just by being an AWS customer? This could be some kid who is learning AWS in his dorm all the way up to a Fortune 50 customer and everyone in between.

Second, how can I utilize these individual services to make sure I'm utilizing AWS threat intelligence to the best of my abilities? Understanding where you have them, where you have gaps, working backwards from what controls or what security challenges you have today, and understanding where you can benefit from some of those services is going to be greatly important to your overall security posture. So with that, I want to say thank you. Please fill out the survey as I'm obligated to say, and we'll hang out outside if people want to ask questions and discuss anything else related to threat intelligence or anything else. Thank you all.

---

; This article is entirely auto-generated using Amazon Bedrock.