Tools & Practice

The tools I use are extensions of the investigative process.

I utilize a curatd list of tools. The following is a peak into my tool bag and practice. The tools I choose are used to observe network behavior, examine network communication, identify information stored on the client, trace where data travels, and correlate individual artifacts into a larger picture of system behavior.

A browser request, a cookie, a DNS response, a packet, or an open port may appear insignificant when examined independently. When those artifacts are collected and correlated, they can reveal how an application communicates, what information it collects, where that information is sent, and what infrastructure supports it.

My technical practice combines network analysis, application-layer analysis, client-side inspection, reconnaissance, and scripting to move from observation to evidence and ultimately to documented findings.

Core Toolset

Tool	Primary Use
Wireshark	Packet capture, protocol analysis, DNS and HTTP traffic inspection
tcpdump	Command-line packet capture and traffic collection
Burp Suite	HTTP/HTTPS interception, request and response analysis, and request manipulation
DevTools	Network, Application, Console, storage, and client-side analysis
Nmap	Network discovery, port scanning, service identification, and infrastructure reconnaissance
Python	Scripting, automation, data processing, and analysis
curl	Direct command-line HTTP requests and response inspection
JavaScript	Client-side inspection and browser-based analysis
theHarvester	data collection,integrates with multiple search engines and APIs

These tools are not used in isolation. Their value increases when observations from one layer can be compared with evidence from another.

00: Reconnaissance

Reconnaissance is the first phase of any technical investigation. Before capturing packets or inspecting application-layer traffic, I gather intelligence about the target environment. This initial information shapes the investigation strategy, identifies potential entry points, and reveals the infrastructure landscape I'll be examining.

Reconnaissance helps answer foundational questions:

What technologies power this application?
What subdomains and related infrastructure exist?
What information is publicly exposed about the organization or service?
What third-party services are integrated?
What security controls or misconfigurations are visible?

Wappalyzer

Wappalyzer is a browser extension and command-line tool that identifies technologies used on websites. It detects content management systems, JavaScript frameworks, analytics tools, advertising networks, payment processors, and hundreds of other technologies.

I use Wappalyzer during reconnaissance to:

Identify the underlying technology stack (e.g., React, Angular, WordPress, Django)
Detect third-party services (analytics, tracking, advertising, CDNs)
Understand the server-side architecture
Identify potential dependencies or vulnerabilities
Map the ecosystem of tools and services integrated into the target

Browser Extension

Instant technology detection while browsing. Available for Chrome, Firefox, Edge, and Safari.

Command-Line Tool

wappalyzer-cli https://example.com — returns structured JSON output for programmatic analysis.

Example Usage

        
# Command-line analysis
wappalyzer-cli https://example.com --json

The output reveals technologies like:

Analytics: Google Analytics, Hotjar, Mixpanel
Ad networks: Google AdSense, Criteo, DoubleClick
CDN: Cloudflare, Akamai, Fastly
JavaScript frameworks: React, Vue.js, Angular
Tracking: Facebook Pixel, Twitter Ads, LinkedIn Insight

This initial technology mapping provides context for the network analysis that follows.

My objective is not simply to inventory the technologies used by the organization.
I use the technology profile as a starting point for understanding dependencies,
concentration points, and potential attack surfaces.

What I Look For

During reconnaissance, I document technologies that appear
within the target environment and take particular note of technologies that are:

Common across multiple organizations
Widely adopted within a particular industry
Shared across otherwise unrelated websites
Responsible for critical application functionality
Associated with known vulnerabilities or CVEs
Present across a large number of potential targets

This changes the question from:

What technology does this organization use?

to:

What technology does this organization depend on, and who else depends on it?

Thinking Beyond the Target

As a Network Security Analyst, my approach to reconnaissance
is from the perspective of analyst as well an adversary.

If I were attempting to disrupt an organization, I would not necessarily limit my attention to the organization itself. I would look for common dependencies that connect multiple organizations.

For example, if reconnaissance reveals that numerous organizations rely on the same third-party platform or technology, that technology becomes interesting from a security perspective. The individual website may not represent the most significant point of exposure. The shared technology may represent a concentration point affecting many organizations simultaneously.

This is particularly important when the technology provides a common function across many environments.

The investigation therefore expands from:

Target Organization
↓
Technology

to:

Target Organization
↓
Shared Technology
↓
Other Organizations
↓
Common Dependency
↓
Potential Concentration Risk

The purpose is not to assume that a shared technology represents a vulnerability.
It is to recognize where a dependency may create a broader attack surface or single point of failure.

When a CVE Changes the Priority

I pay particular attention when a commonly deployed technology is associated with a known CVE.

A known vulnerability changes the investigative priority because the technology is no longer
simply an interesting component of the stack. It becomes a potential security concern
that warrants additional verification.

The analysis then becomes:

        Technology Identified

        ↓

        Version Identified

        ↓

        Known Vulnerability?

        ↓

        CVE / Security Advisory

        ↓

        Is the Affected Version Present?

        ↓

        Is the Vulnerable Component Exposed?

        ↓

        What Is Its Role in the Environment?

Wappalyzer as a mapping tool.

It helps establish:

What technologies are present
Which components appear to be shared dependencies
Which technologies warrant deeper investigation
Where version information may need to be verified
Which components have known security advisories
Where a dependency could create concentration risk

The technology inventory becomes the beginning of the investigation rather than the conclusion.

Reconnaissance identifies the components.

Correlation identifies the dependencies.

Vulnerability research identifies the potential exposure.

Verification determines whether the exposure actually exists.

Harvester (theHarvester)

The Harvester is an OSINT reconnaissance tool that gathers email addresses, subdomains, hosts, employee names, and open ports from various public sources. While often associated with subdomain enumeration, theHarvester integrates with multiple search engines and APIs including:

Shodan reveals exposed devices, services, and open ports
Google, Bing, DuckDuckGo search engine results for domains, emails, and subdomains
LinkedIn employee information and organizational structure
PGP keyservers email addresses associated with the domain
VirusTotal subdomains and related DNS information
SecurityTrails historical DNS and WHOIS data
ThreatCrowd threat intelligence and domain relationships

Beyond Subdomains

TheHarvester's Shodan integration reveals exposed services, open ports, geographic locations, and device types. This turns a domain name into a map of the entire exposed infrastructure — from web servers to database ports, SSH services to IoT devices.

Example Usage

        # Basic subdomain enumeration
theHarvester -d example.com -b google,bing
      

        # Including Shodan for infrastructure discovery
theHarvester -d example.com -b shodan --limit 100
      

        # Full reconnaissance across multiple sources
theHarvester -d example.com -b all -l 500
      

What TheHarvester Reveals

Emails & Employees

Employee email addresses, names, and job titles — often revealing organizational structure and potential targets.

Subdomains & Hosts

Discovered subdomains like dev.example.com, staging.example.com, admin.example.com.

Shodan Intelligence

Open ports, exposed services, operating systems, and geographic distribution of infrastructure.

Example Output Structure

        # Sample findings
[*] Email addresses found:
- admin@example.com
- developer@example.com
- marketing@example.com

[*] Subdomains found:
- api.example.com
- dev.example.com
- mail.example.com
- staging.example.com

[*] Shodan results:
- 192.0.2.1:443 (HTTPS) - nginx/1.18.0
- 192.0.2.2:22 (SSH) - OpenSSH 8.2
- 192.0.2.3:3306 (MySQL) - MySQL 5.7
      

Integration with Other Tools

TheHarvester's output feeds directly into the later phases of investigation:

Subdomains → DNS Analysis: Resolve discovered subdomains and investigate their infrastructure
IPs & Ports → Nmap: Scan discovered IPs for services and vulnerabilities
Emails → Correlation: Check if email addresses appear in cookies, headers, or sessions
Shodan data → Network Analysis: Understand what services are exposed and where

Workflow Integration

Reconnaissance Phase

Use Wappalyzer to understand the technology stack and theHarvester to map infrastructure.

Target Identification

Identify the most interesting subdomains, IPs, or services discovered during recon.

Network & Application Analysis

Move to Wireshark, Burp Suite, and Browser DevTools for deeper investigation of discovered targets.

Correlation

Connect recon findings with observed network traffic — confirm discovered subdomains are making requests.

Recon in Practice

Wappalyzer tells you what technologies a site uses. TheHarvester tells you what infrastructure exists. Together, they provide the roadmap for your network analysis — you know where to look before you even open Wireshark.

01: Network & Packet Analysis

Wireshark

Wireshark provides packet-level visibility into network communications.

I use it to examine traffic generated during an investigation, identify protocols and endpoints, inspect DNS activity, follow conversations, and correlate network traffic with behavior observed in the browser or application.

Areas of Analysis

HTTP and HTTPS traffic
DNS queries and responses
TCP conversations
Request and response headers
Cookie transmission
Redirect behavior
Connections to third-party infrastructure
Network destinations
Traffic associated with application activity

Example Filters

http

Filter HTTP traffic.

http.response.set_cookie

Identify responses containing Set-Cookie.

http.request.cookie

Identify requests containing cookies.

dns.flags.response == 1

Identify DNS responses.

dns.resp.type == 5

Identify CNAME records.

http contains "cookie_name"

Search HTTP traffic for a specific cookie or value.

Packet analysis provides a second perspective on application behavior. What appears in the browser can be compared against what is actually transmitted across the network.

tcpdump

tcpdump provides command-line traffic capture.

I use it when I need lightweight packet collection, particularly when working from Linux or when a graphical interface is unnecessary.

A captured PCAP can subsequently be examined in Wireshark for deeper protocol and conversation analysis.

This provides a practical workflow:

Capture → Preserve → Analyze → Document

The packet capture becomes an evidentiary artifact that can be revisited as the investigation develops.

02: Application & HTTP Analysis

Burp Suite

Burp Suite provides visibility into the HTTP/HTTPS layer between the browser and an application.

I use it to examine requests and responses, inspect headers, identify cookies, analyze parameters, and replay requests when additional investigation is required.

HTTP Analysis

During an investigation I examine:

Request headers
Response headers
HTTP methods
URLs and paths
Query parameters
Request bodies
Response bodies
Cookie headers
Set-Cookie headers
Session behavior
Third-party requests
Tracking endpoints
Redirects

Cookie Analysis

Burp provides a useful view of cookies as they move between the client and server.

I document:

Cookie names
Cookie values
Domain scope
Path scope
Expiration
Session versus persistent behavior
Secure attribute
HttpOnly attribute
SameSite attribute
First-party versus third-party context

I also examine the relationship between:

Set-Cookie

and:

Cookie

The first shows what the server asks the browser to store. The second shows what the browser subsequently sends.

That distinction is important when determining how an identifier is established and how it persists across requests.

Request Manipulation

When additional testing is appropriate, requests can be sent to Repeater for controlled examination.

This allows me to modify and replay requests to investigate application behavior rather than relying exclusively on what the browser presents.

curl

curl provides a direct method of interacting with HTTP services without relying on the browser.

I use it to examine endpoints, inspect responses, compare server behavior, and isolate HTTP behavior from browser-specific activity.

This is particularly useful when I want to answer a simple question:

What does the server return when I ask it directly?

Using curl alongside browser and Burp observations helps distinguish application behavior from client-side behavior.

03: Browser & Client-Side Analysis

Browser DevTools

Browser DevTools provides visibility into what happens inside the browser.

I use the Network, Application, and Console panels as complementary sources of evidence.

The Network panel shows communication.

The Application panel shows client-side storage.

The Console provides a programmable interface for examining browser properties and client-side behavior.

Stateful Analysis

Stateful analysis focuses on information that persists or participates in maintaining a relationship between the browser and an application.

HTTP Cookies

I examine cookies to determine:

What identifiers are created
Who creates them
Which domain receives them
How long they persist
Which paths can access them
Whether security attributes are present
Whether they appear to be functional, session-related, or tracking-related

Browser Workflow

Application → Cookies → Target Domain

I review the complete cookie inventory and compare it before and after browsing activity.

I also distinguish between first-party and third-party cookies.

Evidence I Record

        Cookie name
        Value
        Domain
        Path
        Expiration
        SameSite
        Secure
        HttpOnly
        Session / persistent
        First-party / third-party
      

Cookies provide one view of state. They are therefore examined alongside other storage mechanisms rather than treated as the complete picture.

localStorage & sessionStorage

Browser storage can contain information that does not appear in the cookie inventory.

I examine both:

localStorage
sessionStorage

The investigation focuses on the keys, values, persistence characteristics, and nature of the information being stored.

Browser Workflow

Application → Storage → localStorage / sessionStorage

Console Analysis

        console.log(localStorage);

        console.log(sessionStorage);

To inspect a specific item:

console.log(localStorage.getItem('key_name'));

To enumerate stored values:

        for (let i = 0; i < localStorage.length; i++) {

        const key = localStorage.key(i);

        console.log(key + ': ' + localStorage.getItem(key));

        }

Storage may contain identifiers, preferences, application state, tracking information, or other client-side data.

I document:

Keys
Values
Data types
Storage size
Persistence
Sensitive information exposure
Domain context

Sensitive values are truncated or redacted when documentation requires it.

ETag & Cache Analysis

HTTP caching mechanisms can provide another source of identifiers and behavioral information.

I examine:

ETag
If-None-Match
Cache-Control
Revalidation behavior

Burp Suite

I compare response and request headers across multiple requests to determine how cache identifiers are established and reused.

Wireshark

Relevant filters include:

http.response.etag

and:

http.request.if_none_match

The objective is not simply to locate an ETag, but to understand its behavior.

I document:

ETag values
Whether values remain consistent
Whether values appear unique
Revalidation behavior
Cache-control directives

IndexedDB

IndexedDB provides another browser-based storage mechanism.

I inspect:

Database names
Object stores
Record keys
Record values
Data size
Sensitive information

The investigation follows:

Application → IndexedDB → Database → Object Store → Records

This extends client-side analysis beyond cookies and simple key-value storage.

Stateless Analysis

Not all identifying information requires a persistent identifier.

A browser can disclose characteristics of the device, browser, operating environment, and rendering environment through ordinary requests and client-side APIs.

I therefore separate this portion of analysis into device attributes and fingerprinting behavior.

Device Attributes

HTTP Headers

The HTTP request itself can contain information about the client.

I examine headers including:

        User-Agent
        Accept-Language
        Accept-Encoding
        Accept-Charset
        Referer
        Sec-CH-UA
        Sec-CH-UA-Platform
        Sec-CH-UA-Mobile
        Device-Memory
        DPR
        Viewport-Width
      

These values can reveal characteristics such as:

Browser
Operating platform
Language preferences
Device category
Display characteristics
Browser capabilities

I document the information available from the request and consider how individual attributes may contribute to a broader device profile.

Browser Properties

The Console provides another method of examining the client environment.

        console.log(navigator.userAgent);
console.log(navigator.platform);
console.log(navigator.language);
console.log(navigator.languages);
console.log(navigator.hardwareConcurrency);
console.log(navigator.deviceMemory);

console.log(screen.width, screen.height);
console.log(screen.availWidth, screen.availHeight);

console.log(window.innerWidth, window.innerHeight);
console.log(window.devicePixelRatio);

console.log(navigator.plugins);

console.log(
    Intl.DateTimeFormat().resolvedOptions().timeZone
);
      

These observations can be compared with information visible in network requests.

The objective is correlation:

What the browser knows → What the browser reveals → What the server receives

Canvas Rendering

Canvas rendering can provide a mechanism for distinguishing client environments based on rendering behavior.

I examine whether canvas-based fingerprinting is occurring and whether the resulting output is transmitted elsewhere.

A controlled canvas test can generate a rendering output:

        const canvas = document.createElement('canvas');

canvas.width = 256;
canvas.height = 256;

const ctx = canvas.getContext('2d');

ctx.textBaseline = 'top';
ctx.font = '14px Arial';

ctx.fillStyle = '#f60';
ctx.fillRect(125, 1, 62, 20);

ctx.fillStyle = '#069';
ctx.fillText(
    'Cwm fjordbank glyphs vext quiz, ✌🏽',
    2,
    15
);

ctx.fillStyle = 'rgba(102, 204, 0, 0.7)';
ctx.fillText(
    'Cwm fjordbank glyphs vext quiz, 🙌🏽',
    4,
    17
);

const dataUrl = canvas.toDataURL();

console.log('Canvas output:', dataUrl);
      

Canvas rendering itself does not inherently create network traffic. The investigative question is whether a resulting value is subsequently transmitted to a server.

I therefore compare client-side observations with network traffic.

Evidence

Canvas output
Fingerprinting activity
Frequency of attempts
Destination domains
Data transmitted

WebGL Rendering

WebGL can expose information about the graphics environment.

I examine:

WebGL vendor
Renderer
Version
Shading language version
Supported extensions

Example:

        const canvas = document.createElement('canvas');

const gl =
    canvas.getContext('webgl') ||
    canvas.getContext('experimental-webgl');

if (gl) {
    const debugInfo =
        gl.getExtension('WEBGL_debug_renderer_info');

    if (debugInfo) {
        const vendor =
            gl.getParameter(
                debugInfo.UNMASKED_VENDOR_WEBGL
            );

        const renderer =
            gl.getParameter(
                debugInfo.UNMASKED_RENDERER_WEBGL
            );

        console.log('WebGL Vendor:', vendor);
        console.log('WebGL Renderer:', renderer);
    }

    console.log(
        'WebGL Version:',
        gl.getParameter(gl.VERSION)
    );

    console.log(
        'WebGL Shading Language Version:',
        gl.getParameter(gl.SHADING_LANGUAGE_VERSION)
    );

    console.log(
        'WebGL Extensions:',
        gl.getSupportedExtensions()
    );
}
      

The purpose is to determine whether rendering characteristics are being examined as part of a broader fingerprinting process.

Audio Processing

Audio processing provides another potential source of client-specific characteristics.

I examine whether browser audio APIs are being used to generate measurable output that could contribute to identification.

The investigation includes:

Audio processing behavior
Generated output
Frequency of processing
Whether resulting information is transmitted

As with canvas and WebGL, the important distinction is between capability and observed use.

The presence of an API does not, by itself, establish fingerprinting.

04: DNS & Infrastructure Analysis

DNS Investigation

DNS provides an important connection between application-layer observations and network infrastructure.

I examine:

Requested domains
DNS responses
CNAME records
Resolved addresses
Third-party infrastructure
Relationships between first-party domains and external services

Relevant Wireshark filters include:

dns.flags.response == 1

and:

dns.resp.type == 5

DNS analysis can reveal infrastructure relationships that are not immediately obvious from the visible webpage.

CNAME Cloaking

CNAME analysis is used to investigate cases where a service appears to operate within a first-party domain while ultimately resolving through third-party infrastructure.

The investigative process is:

DNS Query → DNS Response → CNAME → Destination → Infrastructure

I document:

Query domain
Response IP
CNAME record
Destination infrastructure
Third-party relationship
Relevant certificate details

This allows DNS information to be correlated with HTTP requests and browser behavior.

Nmap

Nmap extends the investigation from individual network artifacts into infrastructure reconnaissance.

I use it to investigate:

Hosts
Open ports
Services
Service versions
Operating-system characteristics
Network exposure

Common Scan Types

SYN Scan

nmap -sS <target>

Used for TCP port discovery.

UDP Scan

nmap -sU <target>

Used to investigate UDP services such as DNS, SNMP, or NTP.

Service Detection

nmap -sV <target>

Used to identify services and versions exposed by open ports.

OS Detection

nmap -O <target>

Used to gather operating-system characteristics through TCP/IP behavior.

Full TCP Port Investigation

nmap -sV -p- <target>

This provides a broader view of TCP services exposed by a host.

Nmap results are most useful when they are correlated with information already gathered from browser, DNS, and HTTP analysis.

From Browser Artifact to Infrastructure

One of the more important aspects of my methodology is the ability to move between layers.

For example:

01 — Browser

A request reveals a third-party domain.

02 — DNS

The domain is resolved and its infrastructure relationships are examined.

dig +short analytics.example.com

03 — Network

The resulting host can be investigated with Nmap.

nmap -sV -p- analytics.example.com

04 — Correlation

The results are compared with:

Browser requests
Cookies
HTTP headers
DNS records
Network traffic
Open services
Infrastructure characteristics

The investigation therefore moves beyond:

"I found a tracking request."

and toward:

"I identified the request, established where the domain resolves, examined the infrastructure supporting it, and correlated those observations with the behavior seen at the application layer."

That transition from an isolated browser artifact to an infrastructure-level understanding is a central part of my network analysis practice.

05: Tracking & Evasion Analysis

Bounce Tracking

Bounce tracking can use redirect chains to move a browser through intermediate domains.

I examine redirect behavior through Browser DevTools and network captures.

Browser Investigation

I enable Preserve log and navigate through the application while observing the sequence of requests.

I document:

Complete redirect chain
Intermediate domains
URL paths
Query parameters
Tracking identifiers
Timing and request sequence

The objective is to reconstruct the path rather than examining only the final destination.

First-Party Tracking

Tracking activity does not necessarily require an obviously external tracking domain.

I examine first-party requests for paths and endpoints associated with data collection, including patterns such as:

        /collect
        /pixel
        /track
      

I examine:

Request paths
Query parameters
Payload data
Frequency
Destination
Relationship to user activity

Burp Suite and Wireshark provide complementary perspectives.

Burp exposes the HTTP transaction.

Wireshark provides the network-level observation.

Together, they allow the same behavior to be examined from two layers.

06: Scripting & Automation

Python

Python provides a way to move beyond manual observation.

I use scripting where analysis benefits from:

Repetition
Parsing
Data transformation
Extraction
Comparison
Automation

The purpose is not automation for its own sake.

A script becomes useful when it makes an investigation more repeatable, measurable, or efficient.

JavaScript & Browser Console

The browser Console provides a direct interface to the client environment.

I use JavaScript for targeted examination of:

Browser properties
Storage
Rendering APIs
Client capabilities
Application behavior

This allows me to investigate the client from inside the environment in which the application actually executes.

07: Investigative Workflow

The tools become most useful when combined into a repeatable workflow.

Phase 0: Reconnaissance

Tools: Wappalyzer, theHarvester

gather and organinze data.

Output: Observation, Collection

Phase 1: Capture

Tools: Wireshark, tcpdump

Collect network traffic while interacting with the target.

Output: PCAP, network conversations, DNS activity, HTTP/TLS observations

Phase 2: Application Analysis

Tools: Burp Suite, Browser DevTools

Examine requests and responses.

Output: Cookies, headers, endpoints, parameters, session behavior, third-party requests

Phase 3: Client Storage Analysis

Tools: Browser DevTools, JavaScript

Examine information stored within the browser.

Output: Cookies, localStorage, sessionStorage, IndexedDB, client-side identifiers

Phase 4: DNS Analysis

Tools: Wireshark, DNS utilities

Resolve observed domains and investigate their relationships.

Output: DNS queries, IP addresses, CNAME records, infrastructure relationships

Phase 5: Device & Fingerprinting

Tools: Browser DevTools, JavaScript

Examine information that can contribute to a device profile.

Output: User-Agent, platform, screen, language, time zone, device capabilities, canvas, WebGL, audio

Phase 6: Infrastructure Reconnaissance

Tools: Nmap

Investigate hosts identified during earlier phases.

Output: Open ports, services, service versions, OS characteristics, exposed infrastructure

Phase 7: Correlation

Information gathered from each layer is compared.

            Browser → HTTP → DNS → Network → Infrastructure

The goal: determine whether seemingly separate observations are part of the same behavior.

Phase 8: Documentation

Organize evidence into a documented finding.

What was observed, where, how, what evidence supports it, and what it means in context.

08: What I Look For

Across these methods, I am generally looking for relationships.

Identity

What identifiers are being created, stored, or transmitted?

Persistence

How long does an identifier remain available?

Scope

Which domain, path, service, or application component can access it?

Transmission

Where does information travel?

Correlation

Can information from multiple sources be connected?

Infrastructure

What systems receive or support the communication?

Behavior

What happens when the user interacts with the application?

Exposure

What information is visible at each layer?

09: Evidence Across Layers

A single observation rarely tells the complete story.

Consider a hypothetical identifier:

        Browser
        └── tracking_id
      

The investigation can expand outward:

        Browser
        │
        ├── Cookie
        │ └── tracking_id
        │
        ├── HTTP
        │ └── Cookie: tracking_id=...
        │
        ├── DNS
        │ └── tracking.example.com
        │
        ├── Network
        │ └── destination IP
        │
        └── Infrastructure
        ├── Open ports
        ├── Services
        └── Service versions
      

Each layer adds context.

The resulting analysis is stronger because the conclusion is not based on one artifact alone.

10: Example Analysis Output

A completed investigation can be reduced to a structured set of findings.

HTTP Cookies

            session_id
            First-party
            HttpOnly
            Secure

            tracking_id
            Third-party
            Persistent
          

Browser Storage

            user_token
            Application identifier

            cart_data
            Application state

            tracking_id
            Persistent identifier
          

Device Attributes

            Operating platform
            Browser
            Screen dimensions
            Language
            Time zone
            Device capabilities
          

Fingerprinting

Canvas rendering observed WebGL characteristics observed Client-side processing examined

DNS

            Observed tracking domain
            CNAME relationship
            Resolved infrastructure
          

Redirects

            site.example
            ↓
            intermediate.example
            ↓
            destination.example
          

Infrastructure

443/tcp HTTPS service 8080/tcp HTTP proxy or additional service Additional exposed services

The final interpretation depends on the evidence collected during the investigation.

Tools by Investigative Method

Investigative Method	Primary Tools
HTTP Cookies	Browser DevTools, Burp Suite, Wireshark
localStorage / sessionStorage	Browser DevTools, JavaScript
ETag / Cache Analysis	Burp Suite, Wireshark
IndexedDB	Browser DevTools
HTTP Header Analysis	Browser DevTools, Burp Suite, Wireshark
Device Attribute Analysis	Browser DevTools, JavaScript
Canvas Analysis	Browser DevTools, JavaScript
WebGL Analysis	Browser DevTools, JavaScript
Audio Processing Analysis	Browser DevTools, JavaScript
DNS Analysis	Wireshark, DNS utilities
CNAME Analysis	Wireshark, Burp Suite
Bounce Tracking	Browser DevTools, Wireshark
First-Party Tracking	Wireshark, Burp Suite
Network Discovery	Nmap
Traffic Capture	Wireshark, tcpdump
Direct HTTP Analysis	curl
Automation & Data Analysis	Python

The Bigger Picture

Tools provide visibility.

Methodology provides direction.

Evidence provides support.

Analysis connects the pieces.

My approach is therefore not centered on any individual tool. Wireshark can show me the packet. Burp can show me the request. DevTools can show me what the browser stores. DNS can show me where a domain resolves. Nmap can show me what infrastructure is exposed.

The value comes from bringing those observations together.

        Observe the behavior.
        Capture the evidence.
        Examine each layer.
        Correlate the artifacts.
        Document what the evidence supports.
      

That is how I use technical tools as part of network analysis and research: not simply to identify what is happening, but to build a defensible picture of how the system behaves and what the available evidence reveals about it.