Fix snort emitter crash and remove 'attacker' special actor

Snort emitter: skip events lacking IDS alert fields (sid, message) instead
of crashing on None timestamp. Add Zeek-to-Snort field name mapping as
fallbacks. Add None guard in base emitter threaded path.

Scenario skill: enforce one question per message, add realism review step,
improve threat actor modeling guidance (compromised accounts instead of
'attacker' username), require realistic naming for attacker infrastructure.

Validation: remove 'attacker' as special-cased valid actor — storyline
actors must now be defined users. Update tests accordingly.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Author: DavidJBianco

commands/eforge/scenario.md

@@ -29,6 +29,8 @@ Your job is to understand what the user wants, ask smart questions to fill gaps,
 
 Use a hybrid approach: let the user describe their idea first, then ask targeted follow-up questions to fill gaps. Don't present a checklist — have a conversation.
 
+**Ask exactly ONE question per message.** Never bundle multiple questions in a single turn — it's overwhelming and users tend to only answer the first one. Use the `AskUserQuestion` tool if it's available to you; fall back to a conversational question if not. Either way, one question at a time. After the user answers, acknowledge briefly (one sentence max) and move to the next topic.
+
 If the user gives a rich description up front, extract as much as you can from it before asking questions. If they're vague ("I need some attack data"), guide them through the key decisions.
 
 ### Key Topics to Cover
@@ -82,7 +84,33 @@ The username format should follow a consistent convention for the organization (
 
 **Service/system accounts** are the exception — names like `svc_backup`, `sql_agent`, or `ftp_service` are fine when needed for the story or environment realism. Only add these when they're needed.
 
-**External threat actors** should use the username `attacker` (or `attacker1`, `attacker2` for multiple). These are excluded from the ENVIRONMENT.md document given to students.
+### Modeling Threat Actors
+
+**External attackers do NOT have their own accounts in the victim organization.** Never create a user called `attacker`, `hacker`, `threat_actor`, or anything obviously malicious. Real attackers operate by:
+
+- **Compromising legitimate accounts** — The attacker gains credentials for an existing user (via phishing, credential stuffing, password spraying, etc.) and uses that account. The storyline `actor` field is the compromised user's username. This is the most common case.
+- **Operating at the system level** — Some attacks don't involve user accounts at all (e.g., exploiting a vulnerable service). The actor can be a system account like `SYSTEM`, `NT AUTHORITY\SYSTEM`, `root`, or the service account running the exploited application.
+- **Creating new accounts (rare)** — If the attacker creates accounts for persistence, those accounts must have blending-in names like `svc_sqlbackup`, `admin.temp`, or `backup.service` — never `attacker1` or `evil_admin`.
+
+**Insider threats** use their own legitimate account — they're already in the users list with a normal name.
+
+### Realistic Naming for Attacker Infrastructure and Tools
+
+Everything the attacker controls should look plausible at first glance. The whole point of threat hunting training is that the data looks realistic — obvious names are a dead giveaway that defeats the exercise.
+
+**C2 servers and malicious domains:**
+- Good: `cdn-assets-update.com`, `analytics-service.net`, `img-hosting-cdn.com`, `graph-api-auth.com`
+- Bad: `evil-c2.com`, `malware-server.net`, `attacker-infra.io`, `hack.evil.com`
+
+**Malicious files and processes:**
+- Good: `svchost_helper.exe`, `update-agent.bin`, `chromium_updater.sh`, `ms-index-service.exe`
+- Bad: `my_password_dumper.exe`, `evil_payload.ps1`, `hack_tool.bat`, `malware.exe`
+
+**Attacker email addresses** (for phishing "From:" lines, etc.):
+- Good: `support@accounts-verify.com`, `noreply@hr-benefits-portal.net`, `j.martinez@consulting-group.com`
+- Bad: `attacker@external`, `hacker@evil.com`, `phishing@malicious.net`
+
+**Exception — real tool names:** When the scenario uses a well-known attack tool, use its real name. `mimikatz.exe` is mimikatz. `PsExec.exe` is PsExec. `nmap`, `Rubeus.exe`, `SharpHound.exe`, `Cobalt Strike` — all fine. The rule is: don't *invent* names that scream "malicious", but don't rename real tools either.
 
 ## Scenario YAML Schema
 
@@ -158,7 +186,7 @@ baseline_activity:
 
 storyline:                        # The attack events to bury in the data
   - time: "+2h"                   # Relative offset from start, or absolute ISO 8601
-    actor: attacker               # Username or "attacker"
+    actor: marcus.chen            # Username of compromised account (or system account)
     system: WS-DEV-01             # Must reference existing hostname
     activity: "Description of what happens"
     details:                      # Flexible dict — activity-specific fields
@@ -191,7 +219,7 @@ The scenario is validated before generation. Common issues to avoid:
 - Every `user.persona` must match a persona name (from inline personas or pre-built library)
 - Every `user.primary_system` must match a system hostname
 - Every `system.assigned_user` must match a username
-- Every storyline `actor` must be a username or "attacker"
+- Every storyline `actor` must be a username defined in the users list (or a system account like `SYSTEM`/`root`)
 - Every storyline `system` must match a system hostname
 - Usernames, hostnames, and IPs must all be unique
 - Network segment `systems` must reference existing hostnames
@@ -332,7 +360,8 @@ After generating the scenario YAML, also create an `ENVIRONMENT.md` file in the
 - Include ALL users who appear in the storyline (their accounts show up in the attack data, so students need to be able to look them up)
 - Add 5–15 additional users from the background population, mixed in with the storyline users
 - For very large scenarios (50+ users), include a representative subset — not all of them
-- **Exclude all external threat actors** (username "attacker", "attacker1", etc.) — these should never appear in the document
+- **Exclude any accounts the attacker created** during the attack (e.g., persistence accounts like `svc_sqlbackup`) — these wouldn't exist in the org's directory beforehand
+- **Include every legitimate user whose account gets compromised** — students will see activity under that username and need to look them up
 - Use natural role names, not raw persona codes. Persona "hr" becomes "Human Resources", "sysadmin" becomes "System Administrator", "developer" becomes "Software Engineer", etc.
 
 **Timezone:**
@@ -354,9 +383,17 @@ After the interview, generate both files:
 
 1. **Scenario YAML** — Write to the user's chosen path (default: `scenarios/<scenario-name>.yaml`)
 2. **ENVIRONMENT.md** — Write alongside the scenario YAML
-3. **Validate** — Run `uv run eforge validate <scenario-file>` to check schema and cross-references
-4. If validation fails, fix the issues and re-validate
-5. **Summarize** what was created: environment size, time window, attack narrative overview, log formats
+3. **Realism Review** — Before validating, review the entire scenario as a tough-but-fair devil's advocate. Check:
+   - **Attack realism**: Does the attack chain make sense? Would a real attacker do this in this order? Are there missing steps (e.g., no reconnaissance before lateral movement, no persistence after initial access)?
+   - **Technical accuracy**: Are command lines correct for the target OS? Are process paths right? Do the MITRE ATT&CK technique IDs match what's actually happening?
+   - **Naming realism**: Are all attacker-controlled artifacts (domains, files, processes, created accounts) plausibly named? Would any name immediately tip off a defender? Check for names like `attacker`, `evil.com`, `malware.exe`, `@external`, or anything that screams "malicious".
+   - **Environmental consistency**: Do the users, systems, and network make sense together? Would this org realistically have this infrastructure?
+   - **Timing realism**: Are attack events spaced realistically? (Not crammed into 30 seconds, not dragged over days with no activity)
+   - **Detection opportunity**: Is there enough signal for a hunter to find the attack while still requiring genuine effort?
+   If you find issues, fix them. Tell the user what you changed and why.
+4. **Validate** — Run `uv run eforge validate <scenario-file>` to check schema and cross-references
+5. If validation fails, fix the issues and re-validate
+6. **Summarize** what was created: environment size, time window, attack narrative overview, log formats
 
 If the user wants to immediately generate logs, suggest using `/eforge generate` or running `uv run eforge generate <scenario-file>`.
 

src/evidenceforge/generation/emitters/base.py

@@ -112,9 +112,10 @@ def _run(self) -> None:
                 # Try to get event from queue with timeout
                 event_data = self._event_queue.get(timeout=0.1)
 
-                # Render and buffer the event
+                # Render and buffer the event (None means skip)
                 rendered = self._render_event(event_data)
-                self._buffer_event(rendered)
+                if rendered is not None:
+                    self._buffer_event(rendered)
 
                 # Mark task as done
                 self._event_queue.task_done()

src/evidenceforge/generation/emitters/snort.py

@@ -16,24 +16,37 @@ def emit_event(self, event_data: dict[str, Any]) -> None:
             self._emit_threaded(event_data)
         else:
             rendered = self._render_event(event_data)
-            self._buffer_event(rendered)
+            if rendered is not None:
+                self._buffer_event(rendered)
 
-    def _render_event(self, event_data: dict[str, Any]) -> str:
+    def _render_event(self, event_data: dict[str, Any]) -> str | None:
         """Render Snort/Suricata alert to fast alert format.
 
+        Returns None if the event lacks required IDS alert fields (sid, message,
+        classification), which means it's a plain connection event that should
+        not generate an IDS alert.
+
         Format: <timestamp> [**] [<sid>:1:1] <message> [**] [Classification: <class>] [Priority: <pri>] {<proto>} <src_ip>:<src_port> -> <dst_ip>:<dst_port>
         """
+        # Skip events that lack IDS-specific fields — normal network connections
+        # routed here by network_visibility should not produce alerts
+        if not event_data.get('sid') and not event_data.get('message'):
+            return None
+
+        # Map Zeek field names to Snort field names as fallbacks
+        proto = event_data.get('protocol') or event_data.get('proto')
+
         context = {
-            'timestamp': event_data.get('timestamp'),
+            'timestamp': event_data.get('timestamp') or event_data.get('ts'),
             'sid': event_data.get('sid'),
             'classification': event_data.get('classification'),
             'priority': event_data.get('priority'),
-            'protocol': event_data.get('protocol'),
-            'src_ip': event_data.get('src_ip'),
-            'src_port': event_data.get('src_port'),
-            'dst_ip': event_data.get('dst_ip'),
-            'dst_port': event_data.get('dst_port'),
-            'message': event_data.get('message')
+            'protocol': proto.upper() if proto else None,
+            'src_ip': event_data.get('src_ip') or event_data.get('id.orig_h'),
+            'src_port': event_data.get('src_port') or event_data.get('id.orig_p'),
+            'dst_ip': event_data.get('dst_ip') or event_data.get('id.resp_h'),
+            'dst_port': event_data.get('dst_port') or event_data.get('id.resp_p'),
+            'message': event_data.get('message'),
         }
 
         # Render template

src/evidenceforge/models/scenario.py

@@ -245,7 +245,7 @@ class StorylineEvent(BaseModel):
 
     Attributes:
         time: Event time (ISO 8601, relative offset like "+2h30m", or seconds "+7200")
-        actor: Username or "attacker" for external actor
+        actor: Username of the account performing the action (compromised account or system account)
         system: Target system hostname
         activity: Natural language activity description
         details: Optional activity-specific details (flexible dict)

src/evidenceforge/validation/schema.py

@@ -157,14 +157,14 @@ def _validate_storyline_references(self) -> None:
             return
 
         for idx, event in enumerate(self.scenario.storyline):
-            # Validate actor (must be user or "attacker")
-            if event.actor not in self.usernames and event.actor != "attacker":
+            # Validate actor (must be a defined username)
+            if event.actor not in self.usernames:
                 self.issues.append(
                     ValidationIssue(
                         severity="error",
                         field_path=f"storyline.{idx}.actor",
                         message=f"Storyline event references undefined actor '{event.actor}'",
-                        suggestion=f"Available users: {', '.join(sorted(self.usernames))}, or use 'attacker'",
+                        suggestion=f"Available users: {', '.join(sorted(self.usernames))}",
                     )
                 )
 

tests/unit/test_validation.py

@@ -255,7 +255,7 @@ def test_invalid_group_member(self):
         assert "testuser" in issues[0].suggestion
 
     def test_invalid_storyline_actor(self):
-        """Storyline actor not in users and not 'attacker' should error."""
+        """Storyline actor not in users list should error."""
         scenario = Scenario(
             version="1.0",
             name="test",
@@ -311,10 +311,9 @@ def test_invalid_storyline_actor(self):
         assert issues[0].field_path == "storyline.0.actor"
         assert "nonexistent_actor" in issues[0].message
         assert "testuser" in issues[0].suggestion
-        assert "attacker" in issues[0].suggestion
 
-    def test_valid_attacker_actor(self):
-        """Storyline actor 'attacker' should be valid."""
+    def test_actor_must_be_in_users_list(self):
+        """Storyline actor must be a defined user, even if named 'attacker'."""
         scenario = Scenario(
             version="1.0",
             name="test",
@@ -349,7 +348,7 @@ def test_valid_attacker_actor(self):
             storyline=[
                 StorylineEvent(
                     time="2024-01-15T10:30:00Z",
-                    actor="attacker",  # Valid special actor
+                    actor="attacker",  # Not in users list — should fail
                     system="TEST-01",
                     activity="malicious activity",
                     details={}
@@ -365,9 +364,10 @@ def test_valid_attacker_actor(self):
         validator = ScenarioValidator(scenario)
         issues = validator.validate()
 
-        # Should only have 0 issues (attacker is valid)
-        assert len(issues) == 0
-        assert not validator.has_errors()
+        # "attacker" is not in the users list, so it should be flagged
+        assert len(issues) == 1
+        assert issues[0].severity == "error"
+        assert "attacker" in issues[0].message
 
     def test_invalid_storyline_system(self):
         """Storyline system not in systems list should error."""
@@ -405,7 +405,7 @@ def test_invalid_storyline_system(self):
             storyline=[
                 StorylineEvent(
                     time="2024-01-15T10:30:00Z",
-                    actor="attacker",
+                    actor="testuser",
                     system="NONEXISTENT-01",  # Invalid
                     activity="malicious activity",
                     details={}
@@ -904,7 +904,7 @@ def test_valid_event_sequence(self):
             storyline=[
                 StorylineEvent(
                     time="2024-01-15T10:30:00Z",
-                    actor="attacker",
+                    actor="testuser",
                     system="TEST-01",
                     activity="multi-step attack",
                     event_sequence=[
@@ -940,7 +940,7 @@ def test_event_sequence_missing_sub_event_type(self):
             storyline=[
                 StorylineEvent(
                     time="2024-01-15T10:30:00Z",
-                    actor="attacker",
+                    actor="testuser",
                     system="TEST-01",
                     activity="multi-step attack",
                     event_sequence=[
@@ -987,7 +987,7 @@ def test_none_optional_fields_no_issues(self):
             storyline=[
                 StorylineEvent(
                     time="2024-01-15T10:30:00Z",
-                    actor="attacker",
+                    actor="testuser",
                     system="TEST-01",
                     activity="simple attack",
                     # event_sequence=None (default)