Once an attacker holds a valid session, whether through a stolen cookie, malware in the victim's browser or a script replaying a login, authentication checks have already passed, and only the way the session behaves can show that something is wrong. MITRE D3FEND names this countermeasure Web Session Activity Analysis (D3-WSAA) and defines it as "Monitoring changes in user web session behavior by comparing current web session activity to a baseline behavior profile or a catalog of predetermined malicious behavior." It sits under the Detect tactic as a child of User Behavior Analysis. This card covers what D3-WSAA measures, why D3FEND lists no ATT&CK mapping for it, where it is implemented, how to verify it and where it fails. It is written for application security, fraud and detection engineering teams; the wider analytics discipline is in the UEBA Guide.
Key takeaways
- It works on behaviour inside the session. D3FEND's data points are clicks, time between clicks, form filling, page order and file downloads, compared with a user's profile or with known malicious patterns.
- D3FEND lists no ATT&CK techniques for it. As checked in November 2026, the D3FEND page shows no related offensive techniques; any mapping on this page is labelled as NHI Mgmt Group's view.
- Its natural targets are hijacked and automated sessions. The references D3FEND cites describe detecting man-in-the-browser attacks and fraudulent website use from timing and navigation anomalies.
- False positives are the known cost. D3FEND's considerations name them first, along with attackers who mimic normal behaviour closely enough not to trigger an alert.
- It needs good session logging first. Without per-session event records keyed to a stable session reference, there is nothing to profile.
D3-WSAA at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-WSAA (d3f:WebSessionActivityAnalysis) |
| Tactic | Detect |
| Parent technique | User Behavior Analysis |
| Digital artefact | Web Resource Access (D3FEND relation: analyzes), defined as a request for a network resource and any response, using a standard web protocol |
| ATT&CK mapping in D3FEND | None listed (checked November 2026) |
| ATT&CK mitigation linked in D3FEND | M1040 Behavior Prevention on Endpoint (D3FEND lists D3-WSAA as related) |
| D3FEND references | Four patents: Silver Tail Systems (vector velocity analysis of website use), EMC (detecting attacks including man-in-the-browser), Sophos (host intrusion prevention using user behaviour analysis), Palo Alto Networks (preemptive forensics). D3FEND notes that citing a reference does not mean a product implements it |
| Typical data sources | Application session logs, web server and reverse proxy logs, client-side telemetry, bot management and fraud platform signals |
| Main limitation | Probabilistic; tuning is continuous and depends on traffic volume per user |
How it works
D3FEND describes two comparison modes. In the first, session data collected over time builds a user behaviour profile, and the current session is compared against it to estimate how likely it is to be malicious. In the second, the session is compared against predetermined malicious behaviour profiles, which D3FEND says are developed by analysing malware at run time in a threat research facility.
The EMC patent D3FEND cites shows what this looks like in practice. It groups requests into sessions using identifiers of decreasing reliability (TLS session, login ID or cookie, IP address, then headers such as User-Agent), estimates how long the client takes to act on each page, checks whether page transitions follow real links on the site, weights state-changing requests more heavily than page views, and combines the comparisons into a score for the likelihood of a man-in-the-browser attack.
Signals and what they suggest
| Signal | Normal pattern | Anomaly that may indicate |
|---|---|---|
| Time between actions | Human reading and typing pauses, consistent per user | Machine-regular or near-zero intervals: automation or a script driving the browser |
| Page order | Transitions follow links and menus | Direct jumps to deep transaction pages: replayed requests or a hijacked session |
| Form filling | Typing time proportional to field length | Instant completion or pasted values on fields users normally type |
| Downloads and exports | Occasional, matching the role | Bulk export early in the session: data theft after takeover |
| Session attributes | Stable IP range and User-Agent within a session | Mid-session change of IP or User-Agent: possible cookie theft and replay |
| Session identifiers presented | One identifier per client | Many different session IDs from one source: guessing or brute force, per the OWASP Session Management Cheat Sheet |
The OWASP Session Management Cheat Sheet notes that binding a session to IP address or User-Agent helps detect hijacking but cannot be the only defence, because victims can share an IP address behind NAT or a proxy and User-Agent strings can be spoofed. Treat these as score inputs, not verdicts.
Where identity fits
D3-WSAA profiles human web sessions. Service accounts, API clients and AI agents that call web applications do not click, read or type, so a human-behaviour model will flag them constantly or must exclude them. Give non-human callers their own credentials and their own baseline (expected endpoints, call rate, source workload) rather than letting them share a human user's session. Agents that browse on a user's behalf blur the line further; the Session Hijacking and Cookie Theft Guide covers the token side of the problem.
ATT&CK techniques and D3-WSAA
D3FEND lists no ATT&CK technique for D3-WSAA. The rows below are NHI Mgmt Group's view of where session behaviour analysis can contribute, not D3FEND mappings. Each ID was checked against ATT&CK v20.
| ATT&CK ID | Technique | How session behaviour can help (our view) |
|---|---|---|
| T1185 | Browser Session Hijacking | Malware acting inside the user's browser produces timing and navigation the user does not, the man-in-the-browser case in D3FEND's references |
| T1550.004 | Use Alternate Authentication Material: Web Session Cookie | A replayed cookie appears as a session with a new client fingerprint, direct deep-page access and no normal navigation |
| T1539 | Steal Web Session Cookie | Not detected at the theft itself; the subsequent use is what session analysis sees |
Technique detail is in MITRE ATT&CK T1185 Browser Session Hijacking and MITRE ATT&CK T1539 Steal Web Session Cookie. Automated abuse that D3-WSAA also touches, such as credential stuffing (OAT-008), scraping (OAT-011) and account creation (OAT-019), is catalogued in the OWASP Automated Threats to Web Applications project.
Where it is implemented
| Implementation class | What it analyses | Fits when | Watch out for |
|---|---|---|---|
| Fraud detection and behavioural biometrics platforms | Client-side interaction (typing, pointer, navigation) and transaction context, scored per session | Banking, payments and high-value consumer accounts | Client telemetry raises privacy questions and needs disclosure |
| Bot management services | Request timing, client fingerprint and navigation to separate automation from people | Login, sign-up and checkout flows under automated attack | Tuned for bots, less for a human attacker in a stolen session |
| Application-level rules in code or a SIEM | Session lifecycle and action logs with per-user baselines | Internal and B2B applications with moderate traffic | Needs enough history per user to baseline |
| UEBA over web and proxy logs | Per-user access patterns across many applications | Enterprise users of SaaS and internal web apps | Proxy logs lack in-page interaction detail |
Option detail is in the Bot Management Guide and the Transaction Monitoring and Behavioural Biometrics Guide. Small organisations usually start with application rules on session attribute changes and bulk actions; large consumer platforms combine bot management with fraud scoring.
Implementation steps
- Get session logging right first. Log session creation, renewal, destruction, login, logout, privilege changes, timeouts and invalid activity, with timestamp, source IP, resource, event type, result and user ID, as the OWASP Session Management Cheat Sheet recommends. Log a salted hash of the session ID, never the raw value.
- Pick the sessions that matter. Start with flows where takeover causes loss: payments, payee changes, password and MFA changes, bulk export, administrative consoles.
- Baseline in monitor-only mode. Collect two to four weeks of data, build per-user and per-population profiles, and score sessions without acting on them.
- Define graded responses. Low scores: log. Medium: step-up authentication before the sensitive action. High: end the session and require full re-authentication, as ASVS 5.0 V7.5.1 requires before changes to sensitive account attributes.
- Exclude and separate non-human callers. Route API clients, monitoring probes and agents through their own credentials and baselines so they do not distort human profiles.
- Feed outcomes back. Record analyst and customer verdicts on alerts and use them to retune weights, as the EMC patent describes for remediation feedback.
- Roll back safely. Keep scoring changes versioned; if a release spikes step-up prompts, revert the weights and keep logging.
How to verify it works
- Replay test: in a test environment, copy a valid session cookie to a different browser and network and perform a sensitive action. Confirm the score rises and the defined response fires.
- Automation test: drive a test account with a scripted browser at machine speed through a sensitive flow and confirm detection.
- Benign variation test: have real users switch networks or devices mid-session and confirm they are not locked out, only stepped up where policy says.
- Log completeness check: sample sessions and confirm every lifecycle event is present with the hashed session reference.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Replay and automation tests detected | 100% of scheduled tests | Proves the model sees the attacks it is meant for |
| Step-up rate on legitimate sessions | Low and stable after tuning | User friction drives teams to switch detection off |
| Confirmed takeovers first raised by session analysis | Tracked monthly | Shows unique value over login-time controls |
| Time from high score to session termination | Seconds, automated | Limits what a hijacker can do |
| Sensitive flows covered | All flows on the priority list | Coverage of where loss happens |
Limits, bypasses and failure patterns
- Mimicry: D3FEND notes attackers may not differentiate their activity enough to trigger an alert. A human operator in a stolen session who browses normally is hard to separate from the user.
- Thin baselines: users who log in rarely have no useful profile, so population models dominate and precision drops.
- Single-signal verdicts: terminating sessions on an IP change alone locks out mobile users and users behind shared proxies.
- Analysis too late: scoring that runs in a batch job after the session ends detects a payee change after the money has moved. Score before the sensitive action completes.
- Raw session IDs in logs: logging the identifier in clear turns the detection data into a session theft source.
- Mixing machines and people: shared credentials between an integration and a person make every automated call look like a hijack, so real alerts are ignored.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-4 System Monitoring | Monitoring to detect attacks and unauthorised use |
| NIST SP 800-53 Rev 5 | AU-6 Audit Record Review, Analysis, and Reporting | Analysing session records for unusual activity |
| NIST CSF 2.0 | DE.CM-03, DE.AE-02 | Monitoring personnel activity and technology usage; analysing adverse events |
| OWASP ASVS 5.0 | V7.3.1, V7.3.2, V7.5.1, V7.5.2 | Inactivity and absolute session limits, re-authentication before sensitive changes, user view and termination of active sessions |
| MITRE ATT&CK mitigations | M1040 Behavior Prevention on Endpoint | Mitigation D3FEND lists as related |
| MITRE D3FEND | User Behavior Analysis, D3-WSAA | Parent and technique |
Session control requirements are covered in the OWASP ASVS Guide.
Related countermeasures
- Session Duration Analysis (D3-SDA): flags sessions that run unusually long. See D3-SDA Session Duration Analysis.
- Resource Access Pattern Analysis (D3-RAPA): looks at which resources a user reaches rather than how they navigate. See D3-RAPA Resource Access Pattern Analysis.
- User Geolocation Logon Pattern Analysis (D3-UGLPA): checks where sessions start. See D3-UGLPA User Geolocation Logon Pattern Analysis.
- Multi-factor Authentication (D3-MFA): the step-up response a high score triggers. See D3-MFA Multi-factor Authentication.
Practitioner checklist
- Log the full session lifecycle with a salted hash of the session ID.
- Prioritise payment, credential change, export and admin flows.
- Baseline in monitor-only mode before any automated response.
- Combine several signals; never end sessions on one attribute change alone.
- Score before sensitive actions complete, not after the session ends.
- Map scores to graded responses: log, step-up, terminate and re-authenticate.
- Give API clients and agents separate credentials and baselines.
- Run replay and automation tests on a schedule and track results.
- Feed confirmed outcomes back into tuning.
Standards and references
- MITRE D3FEND: Web Session Activity Analysis (D3-WSAA)
- OWASP: Session Management Cheat Sheet
- OWASP: Application Security Verification Standard 5.0
- OWASP: Automated Threats to Web Applications
- EMC IP Holding: US20110302653A1, detection of attacks through partner websites
- MITRE ATT&CK: T1185 Browser Session Hijacking
- MITRE ATT&CK: M1040 Behavior Prevention on Endpoint
Related NHI Mgmt Group resources: UEBA Guide · Session Hijacking and Cookie Theft Guide · Account Takeover Prevention Guide · MITRE D3FEND Guide