Security teams spend most of their time looking inward — at logs, alerts, and their own infrastructure. The work covered here points outward: investigating phishing infrastructure, monitoring for exposed assets, tracking threat actor activity, and gathering the external context that turns an alert into an understanding.
That outward work has a specific operational requirement that internal security work doesn't. When you investigate someone, they can see you looking. Attackers monitor their own infrastructure. A phishing kit logs its visitors. A malicious domain's operator watches for corporate IP ranges and security vendor infrastructure, and adjusts accordingly — cloaking the malicious content, tearing down the operation, or simply learning which organisations are paying attention.
This guide covers what external security research involves, why attribution control matters, how adversary cloaking works, what to collect and how, and the operational security practices that keep an investigation from announcing itself.
What This Discipline Covers
Several related activities that share the same infrastructure requirements.
Phishing infrastructure investigation. Examining sites impersonating your organisation or your customers' — what they collect, where it goes, what kit they're built on, and what other infrastructure they connect to.
Threat intelligence gathering. Collecting indicators, tracking campaigns, and monitoring the sources where threat activity is discussed or advertised.
Attack surface monitoring. Finding your own organisation's exposed assets — forgotten subdomains, misconfigured services, credentials in public repositories, and data in places it shouldn't be. This is the one activity in the list that requires no adversary contact and consistently produces the most immediately actionable findings.
Malware distribution analysis. Understanding how malicious files are delivered, from where, and to which targets, without executing anything.
Vulnerability and exposure research. Tracking disclosed vulnerabilities against your technology stack and understanding real-world exploitation.
Brand and executive impersonation monitoring. Overlapping substantially with brand protection but with a security framing — credential harvesting rather than counterfeit sales.
Third-party and supply chain monitoring. Watching the security posture of vendors whose compromise would affect you.
Incident support. During an incident, rapidly gathering external context on the infrastructure involved.
Why Attribution Control Matters
The central operational concern, and the one that separates this from ordinary web research.
Adversaries watch their visitors. Phishing kits log requests. Malicious infrastructure is monitored by its operators. Criminal marketplaces track who browses them. When you investigate from identifiable infrastructure, several things follow:
- They know which organisations are looking, which tells them who they've successfully targeted and who's paying attention.
- They can cloak specifically against you, serving benign content to your ranges while continuing to attack your users.
- They can tear down and rebuild before you finish gathering evidence, moving to infrastructure you haven't found.
- They learn your detection capability, which informs how they evade it next time.
- Your investigations become linkable. If the same address examines a series of unrelated infrastructure, an observer can connect those investigations and infer what you know.
Corporate IP ranges are the specific problem. Organisational address space is registered, publicly attributable, and often the first thing an adversary excludes. Security vendor infrastructure is similarly well known and widely blocked.
Datacenter addresses are weak here too. Hosting ranges are commonly excluded by cloaking logic, both because they correlate with automated scanning and because security researchers frequently use them. An investigation from a cloud provider's range is anonymous in the sense that it doesn't name your company, and conspicuous in the sense that it clearly isn't a normal visitor.
What good attribution control looks like:
- Residential or mobile addresses that present as ordinary consumer traffic
- Geographic positioning consistent with the campaign's apparent targets
- Separate identities per investigation, so distinct matters can't be correlated
- No reuse of an address across unrelated investigations
- Fingerprint consistency, so the client resembles a browser rather than a tool
> Tip: The question to ask before any external investigation is "what does this look like from their side?" If the answer is "a request from a corporate range or a cloud provider," you've told them something before you learned anything.
Passive Sources Worth Monitoring
A large share of useful external intelligence comes from public sources that require no adversary contact at all, which makes them both safe and cheap.
Certificate transparency logs. Every publicly trusted TLS certificate is logged, and the logs are queryable. This surfaces domains as they're provisioned — frequently before a phishing site is live, indexed, or has sent a single email. For both attack surface monitoring and impersonation detection, this is the earliest signal available.
Domain registration data. New registrations matching your marks or plausible variations. Registration frequently precedes weaponisation by days.
Passive DNS. Historical resolution data showing which domains have pointed at which addresses over time. Invaluable for infrastructure pivoting without ever contacting the infrastructure.
Public code repositories. Credentials, keys, internal hostnames, and configuration committed by mistake. This is a persistent exposure category and monitoring it is straightforwardly worthwhile.
Paste sites and public dumps. Where leaked data and credentials surface.
Vulnerability disclosure feeds. Tracked against your own technology inventory.
Threat intelligence feeds and community sharing. Indicators from other organisations, which are most useful when correlated against your own telemetry rather than consumed as a list.
Public advisories and vendor bulletins for the products in your stack and your vendors' stacks.
Search engine results for your domains, brand terms, and executive names, which surfaces impersonation and exposed content.
The advantage of passive collection: none of it touches adversary infrastructure, so none of it announces anything. Exhaust the passive sources before making contact, both because it's safer and because the passive picture usually tells you what to look at and what conditions to look under.
Infrastructure Pivoting
The technique that turns a single indicator into a picture of an operation, and much of it can be done without contacting anything.
Pivot points that link infrastructure:
- Shared IP addresses and hosting ranges
- Name servers, particularly unusual ones
- Registration details — registrar, registration date clusters, privacy service, and any exposed contact data
- Certificate details, including shared certificates covering multiple domains and identical issuance patterns
- Page content artefacts — identical HTML structure, shared analytics or tag identifiers, matching favicon hashes, and reused imagery
- Phishing kit fingerprints. Kits are reused widely, and their structure, file names, and error handling are recognisable
- Credential exfiltration endpoints, which are frequently shared across many deployments of the same kit and are among the strongest links available
- Registration and deployment timing patterns
Build a graph rather than a list. Record indicators as entities with attributes and let shared attributes reveal the connections. A list of domains is inventory; a graph is intelligence.
Distinguish shared infrastructure from shared operators. Many domains sit on one hosting provider's address without any relationship. Pivoting on a shared IP at a large hosting provider produces noise; pivoting on a shared exfiltration endpoint produces signal. Weight your pivots by how specific they are.
Document the reasoning. If findings support an escalation, how you connected separate infrastructure will be examined.
Watch for reconstitution. Disrupted operations rebuild with the same kits, the same patterns, and often the same endpoints. A documented attribute set makes the rebuild detectable quickly.
Adversary Cloaking
Malicious infrastructure routinely serves different content to different visitors, and understanding how is necessary to defeat it.
Common techniques:
- IP-based exclusion of security vendor ranges, corporate address space, hosting providers, and known scanner infrastructure. Widely deployed and often maintained as commercial blocklists sold to phishing operators.
- Geographic targeting. Malicious content served only to the campaign's target countries, benign content everywhere else. A phishing campaign against one country's bank customers has no reason to show anything to a visitor from elsewhere.
- Referrer requirements. The malicious page loads only when arrived at from the phishing email's link, often with a unique token. Direct URL entry returns a benign page or an error.
- One-time links. The URL works once and then stops, which defeats investigation after the fact unless the first visit was captured properly.
- User agent and device filtering. Mobile-only or desktop-only delivery, and exclusion of anything that looks automated.
- Time windows. Live only during the campaign's active hours, dormant otherwise.
- Behavioural gating. Content revealed only after interaction that a headless client doesn't perform.
- Client-side environment checks. JavaScript that examines the browser for automation indicators before rendering the malicious content.
Defeating it systematically:
- Match the campaign's apparent targeting. Geography, language, and device class as the intended victim would present them.
- Preserve the full URL including tokens and parameters. These frequently carry the access credential for the malicious content.
- Arrive with the expected referrer where the delivery mechanism implies one.
- Vary one dimension at a time when identifying what triggers the cloak, since knowing the trigger is itself intelligence.
- Use a real browser environment. Client-side automation detection is common, and a headless client with obvious automation markers will see the benign version.
- Capture on first contact. One-time links mean there may be no second chance, so the first visit needs full capture rather than a look followed by a return.
- Record every variant, benign and malicious. Demonstrating differential delivery is valuable evidence and pre-empts the "we looked and found nothing" response.
Safe Collection Practices
Investigating malicious infrastructure carries risk that ordinary web research doesn't.
Never execute what you collect. Downloaded files are evidence, not software. Analysis of executables belongs in an isolated environment built for it, and casually opening a sample on a working machine is how incidents start internally. The same applies to documents, archives, and anything that renders — treat collected artefacts as inert data until they reach a purpose-built environment.
Isolate the collection environment. Investigation infrastructure should be segregated from production and corporate networks, with no credentials, no access to internal systems, and no path back.
Assume the page is hostile. Browser exploitation is less common than it was and is not extinct. A disposable, isolated browser environment is the appropriate posture.
Don't submit anything. Entering test credentials into a phishing form generates traffic in the operator's logs, tells them the kit is being examined, and in some jurisdictions raises legal questions. Observe what the form does; don't feed it.
Be careful with automated sandbox submission. Uploading a sample to a public analysis service makes it — and often the fact that your organisation encountered it — visible to anyone watching those services, including the adversary. That may be fine, and it should be a decision rather than a reflex.
Mind what your client leaks. Headers, TLS fingerprint, and browser characteristics all describe your tooling. A distinctive automation signature is itself an identifier that links your investigations.
Log everything you do. Investigation actions should be as auditable as any other security process, both for evidentiary reasons and so a colleague can reconstruct what was done.
Rate-limit yourself. Aggressive collection against adversary infrastructure is noticeable and can prompt teardown before you've finished. It also risks degrading infrastructure that law enforcement may be monitoring for their own reasons, which is a good way to interfere with an operation you didn't know existed.
Operational Security for the Investigation Team
The practices that keep an investigation from revealing more than it learns.
Segregated infrastructure. Investigation systems should sit outside the corporate network, with no domain membership, no corporate credentials, no shared authentication, and no route back to production. If an investigation environment is compromised, it should be a nuisance rather than an incident.
Disposable environments. A fresh browser profile per investigation, discarded afterwards. Persistent profiles accumulate history that links investigations and, worse, may accumulate something you didn't want.
No personal or corporate accounts. Never sign into anything from investigation infrastructure. A logged-in session is an identity, and it defeats every other precaution.
Separate identities per matter. Address, browser profile, and any associated accounts distinct per investigation, so an observer cannot correlate what you're looking at.
Deliberate fingerprint management. A consistent, ordinary-looking browser fingerprint. Automation markers, unusual header sets, and distinctive TLS signatures all identify the tooling and link its uses.
Consistent locale coherence. Address geography, browser locale, timezone, and language should agree. Mismatches are conspicuous and may exclude you from the content you're trying to see.
Documented actions. Every request, every capture, every decision logged. Both for evidentiary integrity and so a colleague can reconstruct the investigation.
Compartmentalise knowledge of the investigation appropriately. Insider risk is real, and premature internal disclosure has tipped off adversaries more than once.
Plan the exit. Know in advance what happens if the investigation is detected, if the infrastructure is torn down, or if the matter needs to escalate to law enforcement.
Review your own external footprint. Your organisation's investigation infrastructure, if it's consistent, becomes an identifiable signature over time. Rotating and varying it is part of the discipline.
What to Capture
Evidence standards in security work need to support both technical analysis and potential escalation to law enforcement or legal action.
For any investigated URL:
- Complete URL including all parameters and tokens
- Full response, headers and body
- The complete redirect chain, since malicious delivery frequently involves several hops through legitimate services
- All resources loaded, including scripts, since the payload often isn't in the initial document
- Screenshots of the rendered page
- Network trace of every request the page generated
- Certificate details where applicable
- Timestamp, precise and with a stated timezone
- The observation environment: exit address, detected geography, device profile, user agent, referrer, and language settings
Infrastructure indicators:
- Domains, subdomains, and their registration details
- IP addresses and hosting provider
- Name servers and DNS configuration
- Certificate details and their transparency log entries
- Any identifiers embedded in page source — analytics IDs, tag containers, third-party keys
- Where collected credentials are sent, which is often the most valuable single indicator
Why the environment record is essential. Cloaked infrastructure serves clean content to most visitors. Your record of what conditions produced the malicious version is what makes the finding reproducible and credible when someone else checks and sees nothing.
Preserve immediately. Malicious infrastructure has a short life. Capture on first contact rather than planning to return.
Phishing Investigation: A Worked Approach
The most common external investigation, and a sequence that avoids the usual failures.
Start with what you have. The full URL from the reported email, including every parameter. Tokens in that URL are frequently the access credential for the malicious page, and truncating them is the single most common reason an investigation sees a benign page.
Exhaust passive sources first. Registration data, passive DNS, certificate history, and whether the domain appears in existing threat reporting. This often establishes the operation's shape before any contact.
Determine the apparent target. Which organisation is being impersonated, which language the lure uses, and which country's customers it addresses. This tells you what your observation environment needs to look like.
Configure the environment to match. Residential address in the targeted country, browser locale and timezone consistent with it, device class matching the delivery method, and the referrer the email link would have produced.
Capture completely on first contact. Full response, complete redirect chain, every resource loaded, screenshots, and a network trace. Assume there is no second visit, because with one-time links there often isn't.
Identify the exfiltration path. Where the kit sends collected credentials — a form action, an API endpoint, an email address in the source, or a chat platform webhook. This is usually the single most valuable indicator, since it's frequently shared across many deployments of the same kit.
Pivot on what you found. Shared endpoints, kit fingerprints, certificate patterns, and registration clusters. This is where one phishing page becomes a map of an operation.
Check for differential delivery. Vary geography, device, and referrer to establish what the cloaking keys on. The difference between the clean and malicious versions is evidence, and knowing the trigger conditions is intelligence.
Hunt internally. Search your telemetry for prior contact with every indicator found. This converts research into incident response when it needs to.
Report and preserve. Takedown through the hosting provider and registrar, with evidence attached, and preserve everything before the notice prompts removal.
Attack Surface Monitoring
The inward-facing half of external research: finding your own exposure before someone else does.
What to look for:
- Forgotten subdomains pointing at decommissioned or third-party infrastructure, which is the classic subdomain takeover exposure
- Certificate transparency entries for domains you didn't know existed, which frequently reveal shadow IT
- Publicly accessible services that shouldn't be — admin interfaces, development environments, staging systems, storage buckets
- Credentials and keys in public code repositories, which is a persistent and entirely avoidable exposure
- Documents and data indexed publicly that were meant to be internal
- Third-party services configured under your brand by teams who didn't tell security
- Exposure in breach compilations affecting your domains
Why external perspective matters. Your internal asset inventory describes what you think you have. External discovery describes what the internet can see, and the gap between those two is where most external compromise begins.
Collect from outside your own network. An attack surface scan run from inside your perimeter sees a different picture from what an attacker sees, and the difference is the point of the exercise.
Third-Party and Supply Chain Monitoring
Your security posture includes organisations you don't control, and monitoring them has both value and clear limits.
What you can observe legitimately:
- Their externally visible infrastructure and technology stack
- Certificate issuance and domain activity
- Public disclosure of breaches or incidents affecting them
- Their exposure in credential dumps and public data
- Publicly known vulnerabilities affecting technologies they visibly use
- Their own public security posture — published policies, disclosure programmes, and certifications
What you cannot do without an agreement: test their systems, probe for vulnerabilities, or attempt any access. Observing public posture is legitimate; assessing security by touching it is not, regardless of your contractual relationship, unless that relationship explicitly permits it.
Practical approach:
- Maintain an inventory of vendors whose compromise would affect you, ranked by that impact
- Monitor passively and continuously rather than assessing annually via questionnaire
- Watch for their domains appearing in breach data and their infrastructure appearing in threat reporting
- Track the technologies they visibly run against disclosed vulnerabilities
- Escalate through the contractual relationship rather than through unilateral testing
The value is in timing. A vendor incident affecting you is usually disclosed to you later than it becomes externally visible. Passive monitoring closes that gap, and closing it is the entire point of the exercise.
Incident Support
During an active incident, external research needs to move fast without abandoning discipline.
What's typically needed quickly: context on the infrastructure involved — who registered it, when, what else it connects to, whether it appears in threat reporting, and what other organisations may be affected.
Prioritise passive sources. Passive DNS, registration data, certificate history, and threat feeds answer most urgent questions without touching anything and without alerting anyone.
Be deliberate about active contact. During an active incident, alerting the adversary can accelerate their actions — destroying evidence, escalating access, or triggering deployment of a secondary payload. The decision to touch their infrastructure should be made consciously, with the response lead, not by a researcher acting alone.
Preserve everything. Incident evidence has a higher probability of ending up in legal or law enforcement hands than routine research.
Keep the investigation compartmented. Incident details spread internally faster than intended, and adversaries with internal access read the same channels.
Document decisions, not just findings. Why you chose to contact infrastructure, why you didn't, and who authorised it. Post-incident review will ask.
Feed findings into containment immediately. External research during an incident is only valuable if the indicators reach blocking and detection quickly.
Proxy and Infrastructure Requirements
Residential addresses for investigation. Consumer ISP classification is what avoids the exclusion lists that target corporate and hosting ranges, and it presents as the kind of visitor a campaign expects.
Geographic positioning matched to the campaign. A phishing operation targeting one country will not show its content to a visitor from elsewhere.
Mobile addresses where the campaign targets mobile users. Smishing and mobile-focused phishing frequently deliver only to carrier networks.
Separate identities per investigation. Reusing an address across unrelated matters lets an observer correlate them and infer the scope of what you're looking at.
Rotation between investigations, not during them. Consistency within a session, separation between them.
Static addresses where a session must persist. Multi-step investigation requiring maintained state needs an address that doesn't change mid-flow.
Never corporate address space. For all the reasons above, and because it's the one thing you cannot undo once observed.
Datacenter has a narrow role. Bulk passive collection from public sources — certificate logs, public repositories, feeds — doesn't need residential classification and is much cheaper without it. Reserve residential for anything where the target might be watching.
Turning Research Into Defence
Intelligence that doesn't change your defensive posture is expensive reading. A few practices that close the loop.
Feed indicators into blocking and detection immediately. Domains, addresses, and hashes discovered externally should reach your controls within minutes, not at the end of a report cycle.
Prioritise by relevance to your environment. A campaign targeting a technology you don't run is background; one targeting your stack, your sector, or your customers is actionable. Generic feed consumption without this filter produces noise and alert fatigue.
Hunt retrospectively. When you discover infrastructure, search your historical telemetry for prior contact with it. Discovering a phishing domain is useful; discovering that forty employees visited it last week is actionable.
Convert patterns into detections. Individual indicators expire quickly — domains rotate, addresses change. The behavioural patterns behind them last longer. A detection built on how a phishing kit exfiltrates survives the domain being replaced.
Inform user-facing defences. Phishing campaigns targeting your users should shape awareness communications, and knowing the specific lure is far more effective than generic warnings.
Track which intelligence proved useful. Most collected indicators never fire. Measuring which sources and which categories actually contributed to a detection lets you invest in what works and stop paying for what doesn't.
Share where appropriate. Sector information-sharing arrangements work better when participants contribute, and infrastructure targeting you is frequently targeting your peers.
Report honestly on what monitoring cannot see. Coverage gaps are the most useful thing an intelligence function can tell its leadership, and they're the thing most often omitted from reporting.
Common Mistakes
Investigating from corporate address space. Tells the adversary exactly who is looking, gets you excluded, and cannot be undone.
Using cloud or hosting ranges for adversary-facing work. Anonymous in the sense of not naming your company, conspicuous in the sense of clearly not being a visitor.
Skipping passive sources first. Certificate logs, passive DNS, and registration data frequently answer the question without any contact at all.
Losing URL parameters. Tokens in a phishing URL are often the access credential for the malicious content. A truncated URL sees a benign page.
Returning for a second look. One-time links exist. Capture completely on first contact.
Executing collected samples. Files are evidence. Analysis belongs in an environment built for it.
Submitting test credentials. Generates traffic in the operator's logs, tells them they're being examined, and raises legal questions.
Reflexive public sandbox submission. Visible to anyone watching those services, adversaries included. Make it a decision.
Reusing addresses across investigations. Lets an observer correlate unrelated matters and infer your scope.
Signing into anything from investigation infrastructure. Defeats every other precaution in one action.
Aggressive collection rates. Noticeable, and prompts teardown before you've finished gathering.
Blurring observation into probing. The legally significant line in this discipline, and the easiest one to cross while feeling productive.
Building the Capability
Phase one — define scope and authorisation. Written authorisation for attack surface work on your own assets, and clear legal boundaries for external investigation. Do this before any technical work, because it determines what the capability is permitted to do.
Phase two — stand up segregated infrastructure. Isolated systems, no corporate credentials, no route back, disposable environments.
Phase three — establish passive collection. Certificate transparency, passive DNS, registration monitoring, public repository scanning. Safe, cheap, and frequently sufficient.
Phase four — build attack surface discovery from an external vantage point, and reconcile it against your internal asset inventory. The gap is the finding.
Phase five — add adversary-facing capability with residential and mobile addresses, geographic targeting, and per-investigation identity separation.
Phase six — evidence handling. Immutable storage, complete environment records, documented chain of custody, and a defined process for escalation.
Phase seven — pivoting and graph analysis, turning individual indicators into infrastructure maps.
Phase eight — integration with detection. External findings should feed your internal telemetry and blocking, or the intelligence stays theoretical.
Phases one and two are the ones that get compressed by urgency during an incident, which is precisely when compressing them causes the most damage.
Legal and Ethical Boundaries
This is the discipline where the boundary between research and offence is sharpest, and getting it wrong has consequences beyond a terms-of-service dispute.
- Observing what a server sends you is fundamentally different from probing it. Requesting a page is not the same as testing it for vulnerabilities, and computer misuse legislation in most jurisdictions cares a great deal about that distinction.
- Do not attempt to access non-public systems. Not adversary infrastructure, not a third party's, not even to confirm a suspicion. Investigation means observation.
- Do not submit credentials, test or otherwise, to a phishing form.
- Unauthorised scanning is a legal risk even with good intentions, and even against infrastructure you believe is malicious.
- Attack surface work on your own assets requires clear internal authorisation, in writing, defining scope. This protects you as much as the organisation.
- Third-party monitoring has limits. Observing a vendor's public posture is fine; testing their systems is not, absent an agreement.
- Data protection law applies to personal data encountered during investigation, including in breach data — which is an area with genuine legal complexity around possession and handling.
- Coordinate with legal and law enforcement where a matter may escalate. Evidence handling and disclosure decisions have consequences.
- Know your organisation's disclosure policy before you find something in a third party's systems.
Not legal advice, and this is the discipline where that disclaimer matters most. The gap between defensible research and a criminal offence is narrower here than anywhere else in this field, and it varies by jurisdiction. Involve counsel in defining the boundaries before an investigation, not during one.
Frequently Asked Questions
Why does the phishing site look benign when I check it?
Cloaking, almost certainly. Your address, geography, referrer, or device profile is outside the campaign's target, or your range is on an exclusion list. Try from a residential address in the targeted country with the original referrer and full URL parameters.
Do I really need residential proxies for this?
For anything where the adversary might be watching, yes. Corporate and hosting ranges are the most commonly excluded, and using them both blinds you and informs them.
Can I investigate from a cloud VPS?
You can, and it's better than corporate space, but hosting ranges are widely excluded and clearly not ordinary visitors. Acceptable for passive collection from public sources, weak for adversary-facing work.
Is it legal to browse malicious infrastructure?
Viewing publicly accessible content is generally not an offence. Probing, testing, or attempting access to non-public functionality is a different matter entirely, and the line is legally significant. Get jurisdiction-specific advice.
Should I submit samples to public analysis services?
Sometimes, deliberately. Public submission is visible to adversaries who monitor those services, and it can reveal that your organisation encountered the sample. Make it a decision rather than a default.
How do I avoid linking my investigations to each other?
Separate addresses and separate browser identities per investigation, with no reuse. Correlation across investigations reveals scope, and scope is intelligence.
What about accessing criminal marketplaces?
Legally fraught, organisationally risky, and generally a matter for specialist teams with explicit authorisation and legal cover rather than something to attempt on your own initiative.
How do I justify the cost of external research?
By measuring time-to-detection and by tracking which findings resulted in a blocked campaign or a closed exposure. Coverage gaps are also worth reporting honestly — leadership generally responds better to a clear statement of what isn't monitored than to a volume count of indicators collected.
How do I handle one-time phishing links?
Capture completely on first contact. There is no second visit, so the first must collect the full response, redirect chain, resources, screenshots, and network trace rather than a quick look.
Getting the Infrastructure Right
Security research is one of the few disciplines where the wrong proxy choice doesn't just degrade your results — it actively informs the adversary. ProxyScrape's residential proxies provide consumer ISP addresses with country and city-level targeting, which is what lets an investigation present as an ordinary visitor from the geography a campaign is actually targeting rather than as a corporate or hosting range that cloaking logic will exclude. For campaigns delivering only to carrier networks — smishing and mobile-focused phishing — their mobile proxies route through 3G, 4G, and 5G connections, while their datacenter plans suit the bulk passive collection from public feeds and logs where nobody is watching. Their cybersecurity documentation covers the setup side.
→ Compare proxy options for threat research and attack surface monitoring
External security research inverts the usual advice in this field. Everywhere else, the counsel is to start cheap and escalate on evidence. Here, the cheap option tells your adversary that a corporate or hosting range is examining their infrastructure, which is information you gave away for free and cannot take back. Investigate from where the campaign expects its victims to be, keep investigations separated from one another, capture completely on first contact because there may not be a second, and be very clear about the line between observing what a server sends you and touching what it doesn't offer.