Most security tools can tell you which IP address a connection came from, but few teams can say how trustworthy that address is, how old the verdict is, or whether the list behind it is still working. MITRE D3FEND names this countermeasure IP Reputation Analysis (D3-IPRA) and defines it as "Analyzing the reputation of an IP address." It sits under the Detect tactic as a child of Identifier Reputation Analysis (D3-IRA), next to Domain Name, File Hash and URL Reputation Analysis. This card covers what D3-IPRA analyses, why D3FEND attaches no ATT&CK technique to it, where it is implemented in email, identity, cloud and network controls, how to prove a reputation feed is live, and how attackers route around it. It is written for detection engineers and SOC leads who already run a threat intelligence programme of some kind; the basics are in the Threat Intelligence Guide.
Key takeaways
- A lookup, not a verdict. D3-IPRA compares an observed IP address with what is known about it from feeds, internal history and provider intelligence. The result is a score or a list match that still needs context before it justifies a block.
- No direct ATT&CK mapping. D3FEND's knowledge base (version 1.6.0, checked November 2026) links D3-IPRA only to the IP Address artefact, and no ATT&CK technique in the D3FEND graph acts on that artefact, so the page lists no ATT&CK techniques for it.
- Freshness decides value. Attacker infrastructure rotates through cloud hosts, residential proxies and compromised devices. A reputation entry without a first-seen and last-seen date ages into a false positive.
- Allow lists matter as much as block lists. Public DNS resolvers, CDN edges and cloud provider ranges appear in malicious traffic constantly; MISP warninglists and provider trusted lists exist to stop them becoming false alarms.
- Test the feed, not just the rule. RFC 5782 defines test entries for DNS-based lists so a client can confirm the zone still works. The same idea applies to every reputation source: plant a known test indicator and confirm the alert fires.
D3-IPRA at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-IPRA (d3f:IPReputationAnalysis) |
| Tactic | Detect |
| Parent technique | Identifier Reputation Analysis (D3-IRA), itself a child of Identifier Analysis (D3-ID) |
| Digital artefact | IP Address (D3FEND relation: analyzes IP Address) |
| D3FEND references | Two patents: "Database for receiving, storing and compiling information about email messages" (US20050091319A1) and "Finding phishing sites" (US8839418B2) |
| ATT&CK mapping in D3FEND | None, direct or inferred (checked November 2026) |
| Typical inputs | Source IPs in mail headers, sign-in logs, web and API access logs, firewall and flow records, DNS answers |
| Typical outputs | Score, category (proxy, Tor, scanner, known malicious), list match with reason text, enrichment on an alert |
| Main limitation | Detects only infrastructure that someone has already seen and reported; fresh or shared addresses pass |
How it works
D3FEND gives D3-IPRA a definition and two references but no "how it works" article, so the mechanics below come from the referenced patents' subject (scoring senders and phishing hosts) and from the standards and product documentation cited on this page. Any implementation has four parts.
- Collection: extract the address that matters. For email this is the connecting MTA address, not an address written into a header by the sender. For web traffic behind a proxy or load balancer, the client address is in a forwarded header, and the control must be told which header it can trust.
- Lookup: query one or more sources. Sources range from DNS-based lists, through commercial and community feeds in STIX, CSV or plain text, to intelligence built into a cloud or identity service.
- Interpretation: turn the answer into meaning. A DNS list returns an A record in 127.0.0.0/8 whose value can mark a sub-list; RFC 5782 says the record marks listing status and is not to be used as an address, and that TXT records usually carry the listing reason.
- Action: enrich, alert, challenge or block. Most mature programmes enrich every event, alert on combinations (a malicious source plus a successful sign-in), and block only on high-confidence categories at the edge.
Reputation categories you will meet
| Category | What it usually means | Safe default use |
|---|---|---|
| Known malicious | Observed attacking, scanning or hosting malware recently | Block at the edge or alert on any success from it |
| Anonymising service (Tor exit, open proxy, VPN) | Origin is deliberately hidden; may be legitimate privacy use | Step-up authentication or extra scrutiny, rarely a hard block for consumers |
| Hosting and cloud provider | Traffic from servers, not end-user devices | Alert for interactive human sign-ins; expected for APIs, webhooks and workloads |
| Known good infrastructure (search crawlers, CDN edges, public resolvers) | Shared, high-volume, frequently appears in logs | Allow list or suppress so it does not create false positives |
| Spam source (DNS list listing) | Address sends unsolicited or abusive mail | Reject or score at SMTP connection time |
ATT&CK techniques and D3-IPRA
D3FEND lists no ATT&CK techniques for D3-IPRA. D3FEND relates defensive and offensive techniques through shared digital artefacts, and the only artefact D3-IPRA analyses is IP Address. No ATT&CK technique in the D3FEND 1.6.0 graph is modelled as acting on an IP Address, so no inferred relation exists either. Its parent D3-IRA does show inferred relations, but those arrive through the URL artefact used by URL Reputation Analysis, not through IP addresses.
In practice, NHI Mgmt Group's view (not a D3FEND mapping) is that IP reputation is most often used as supporting evidence when investigating attacker infrastructure and access techniques such as T1583 Acquire Infrastructure, T1584 Compromise Infrastructure, T1090 Proxy Defensive Guide, and password spraying from rotating sources (see the Password Spraying and Credential Stuffing Defence Guide). Treat those as investigation context, not as coverage claims.
Where it is implemented
Platforms are listed alphabetically; the order is not a ranking. Each row describes the feature from the vendor's own documentation.
| Implementation class | Example feature (vendor documentation) | What it analyses |
|---|---|---|
| Cloud threat detection | Amazon GuardDuty threat lists and trusted lists. Entity lists accept IP addresses, domains and SHA-256 hashes; IP address lists accept IPs only. Up to six threat lists and one trusted list of each kind per account per Region, 35 MB per file, IPv4 only, and the trusted list wins when an address appears in both | CloudTrail, VPC Flow Logs and (for entity lists) Route 53 Resolver DNS query logs |
| Cloud web application firewall | AWS WAF managed groups AWSManagedRulesAmazonIpReputationList (rules AWSManagedIPReputationList, AWSManagedReconnaissanceList, AWSManagedIPDDoSList) and AWSManagedRulesAnonymousIpList (AnonymousIPList, HostingProviderIPList). Google Cloud Armor threat intelligence feeds used with evaluateThreatIntelligence(), such as iplist-known-malicious-ips, iplist-tor-exit-nodes, iplist-anon-proxies and iplist-vpn-providers | Source address of HTTP requests at the load balancer or edge |
| Endpoint and network protection | Microsoft Defender for Endpoint custom indicators for IP addresses with Allow, Audit, Warn or Block execution actions, within a limit of 15,000 indicators per tenant; IPv4 and full IPv6 notation, no wildcards or ranges | Outbound connections from managed devices |
| Identity provider | Microsoft Entra ID Protection sign-in detections: Anonymous IP address (real-time), Malicious IP address (offline), Verified threat actor IP (real-time) | Source address of user sign-ins |
| Mail transfer agents and gateways | DNS-based lists queried at SMTP connection time using the RFC 5782 format | Connecting MTA address |
| SIEM and threat intelligence platforms | Indicator matching of feed entries (STIX, CSV, MISP events) against log fields, with false-positive filtering such as MISP warninglists | Any log field holding an address |
Availability: Google Cloud Armor threat intelligence feeds require a Cloud Armor Enterprise subscription. Microsoft Entra ID Protection's Malicious IP address and Verified threat actor IP detections require Microsoft Entra ID P2; Anonymous IP address is available with Free or P1. Check each vendor's current documentation before planning.
Two documented behaviours catch teams out. AWS states its IP reputation rule groups evaluate the web request origin, so traffic arriving through a proxy or load balancer is judged by the last proxy's address unless the client address is taken from a forwarded header. Microsoft states that network protection decides after the TCP handshake completes, so a blocked connection can still appear as ConnectionSuccess in NetworkConnectionEvents.
Where identity fits
Non-human identities change how reputation should be read. Service principals, CI runners, webhooks and partner integrations normally connect from cloud and hosting ranges, which is exactly what AWS's HostingProviderIPList and Cloud Armor's iplist-public-clouds describe. A hosting-range sign-in is suspicious for a human account and normal for a workload. Split the policy: for workload identities, compare the source against the expected egress ranges for that identity (an allow list per identity) rather than a generic reputation score. See the Impossible Travel and Anomalous Sign-In Detection guide for the human side.
Implementation steps
- Inventory the address fields. List every log source that carries a client IP and record which field is authoritative (connecting MTA, X-Forwarded-For from a trusted proxy, cloud provider source address). Reputation on the wrong field produces confident wrong answers.
- Choose sources by use case. One mail list for SMTP, one provider feed for the edge, internal history from your own incidents, and the built-in intelligence of the identity provider. Record each feed's licence, update interval and categories. The Threat Intelligence Feed Evaluation Guide covers scoring feeds.
- Build the allow side first. Load warninglists or trusted lists for your own egress ranges, partners, public resolvers and CDN edges before you load threat lists.
- Start in monitor mode. Use Count or Audit actions (AWS WAF Count, Defender for Endpoint Audit) or enrichment-only SIEM rules for two to four weeks. Review every match that would have been blocked.
- Promote by category. Move high-confidence categories (known malicious, active scanners) to block at the edge. Keep anonymising and hosting categories as signals that raise risk or trigger step-up authentication.
- Attach expiry. Give internally added indicators an expiry date (for example 30 to 90 days, an NHI Mgmt Group example, not a standard) and re-review on expiry.
- Roll back cleanly. Every block rule should have an owner and a documented switch back to Count or Audit, and partner-impacting blocks should be reversible without a change freeze.
How to verify it works
- Feed health test: for DNS lists, query the RFC 5782 test entries. 127.0.0.2 (IPv6 ::FFFF:7F00:2) must be listed and 127.0.0.1 (::FFFF:7F00:1) must not. A zone that answers both has been wildcarded and will block everything.
- Synthetic indicator test: add a publicly routable address you control (a lab host) to a threat list, generate traffic or a sign-in from that host, and confirm the alert or finding arrives. GuardDuty documents that list changes take about 15 minutes and up to 40 minutes, and that a changed file must be re-activated, so test after that window.
- Status check: confirm every list shows Active or loaded. GuardDuty uses a list only when its status is Active; an Error status silently removes it from detection.
- Field check: sample events and confirm the address evaluated is the client, not the load balancer or mail relay.
- Exercise check: include traffic from an anonymising service or a fresh cloud host in authorised red team work and record which controls flagged it.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Reputation sources passing a monthly synthetic test | 100% | Proves feeds and rules work end to end |
| Share of block-mode matches later confirmed benign | Falling each quarter | Measures false positive cost |
| Median age of indicators in block lists | Tracked and reviewed | Stale entries cause blocks on reassigned addresses |
| Confirmed incidents where the source IP had a prior reputation hit | Tracked per incident | Shows whether the feeds see your attackers at all |
| Log sources with a verified client IP field | All internet-facing sources | Wrong-field lookups make every other metric meaningless |
Limits, bypasses and failure patterns
- Fresh and residential infrastructure: attackers who rent new cloud hosts or route through residential proxies and compromised home routers use addresses with no history. Reputation catches reuse, not novelty, so pair it with behaviour such as failure rates and new-device signals.
- Shared addresses: CGNAT, mobile carriers, corporate VPN egress and cloud NAT put thousands of users behind one address. A block on one bad user blocks all of them.
- Wildcarded or abandoned lists: RFC 5782 warns that a list may be shut down by listing everything, and that abandoned zones can be re-registered with wildcard records. Clients that never check test entries will block all mail.
- Trusting the wrong header: accepting X-Forwarded-For from any client lets an attacker write their own source address. Only read it from proxies you control.
- Hosting-range blocks that break machines: blocking all cloud and hosting addresses stops partner webhooks, monitoring probes and API clients. Scope such rules to interactive human endpoints.
- Privacy and data sharing: RFC 5782 notes that query volume reveals mail volume to the list operator. Sending internal addresses or user data to external lookup services needs a data protection review.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-4 System Monitoring; SI-4(4) Inbound and Outbound Communications Traffic | Monitoring traffic with threat context applied |
| NIST SP 800-53 Rev 5 | SC-7 Boundary Protection | Edge enforcement of reputation blocks |
| NIST SP 800-53 Rev 5 | PM-16 Threat Awareness Program; SI-5 Security Alerts, Advisories, and Directives | Receiving and acting on threat intelligence |
| NIST CSF 2.0 | ID.RA-02, DE.AE-07, DE.CM-01 | Threat intelligence received, integrated into analysis, and networks monitored |
| MITRE D3FEND | D3-ID, D3-IRA, D3-IPRA | Grandparent, parent and technique |
Related countermeasures
- Identifier Reputation Analysis (D3-IRA): the parent. See D3-IRA Identifier Reputation Analysis.
- Domain Name Reputation Analysis (D3-DNRA): the same approach for domains, sharing both D3FEND patent references. See D3-DNRA Domain Name Reputation Analysis.
- Identifier Activity Analysis (D3-IAA): behaviour of an identifier in your own logs, which catches fresh infrastructure that reputation misses. See D3-IAA Identifier Activity Analysis.
- Inbound Session Volume Analysis (D3-ISVA): volume signals that complement reputation during floods. See D3-ISVA Inbound Session Volume Analysis.
- Filter Network Traffic (M1037): the ATT&CK mitigation that enforces blocks. See M1037 Filter Network Traffic.
Practitioner checklist
- Record the authoritative client IP field for every internet-facing log source.
- Keep a register of reputation sources with licence, categories, update interval and owner.
- Load allow lists (own egress, partners, resolvers, CDN edges) before threat lists.
- Run new rules in Count or Audit mode before blocking.
- Block only high-confidence categories; use anonymising and hosting categories as risk signals.
- Treat hosting-range traffic differently for workload identities and human users.
- Query DNS list test entries before trusting a zone, and alert when they fail.
- Run a monthly synthetic indicator test per source and record the result.
- Expire internally added indicators and review them on expiry.
Standards and references
- MITRE D3FEND: IP Reputation Analysis (D3-IPRA)
- IETF: RFC 5782 DNS Blacklists and Whitelists
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- AWS: GuardDuty trusted and threat lists
- AWS: WAF IP reputation rule groups
- Google Cloud: Cloud Armor threat intelligence
- Microsoft Learn: Defender for Endpoint indicators overview
- Microsoft Learn: Microsoft Entra ID Protection risk detections
- MISP Project: misp-warninglists
Related NHI Mgmt Group resources: Threat Intelligence Guide · Threat Intelligence Feed Evaluation Guide · MISP Threat Sharing Guide · Anonymity Networks for Defenders Guide · MITRE D3FEND Guide