Crawford Security Findings: Evidence-Based FNOL Platform Security Research Report

1. Evidence Inventory

1.1 Artifact Index (Session Inputs)

The assessment is grounded exclusively in the following artifacts recovered from the FNOL platform and its client application tier:

1.2 Assessment Scope

Crawford & Company operates at the intersection of Insurance (Claims Management) and Financial Services (TPA Services). The FNOL platform is a critical BFSI infrastructure component handling first notice of loss intake, user lifecycle management, assignment routing, and document tokenization. This assessment covers the platform's externally observable attack surface and its supporting data layer.

• Insurance Claims Processing (FNOL intake, assignment management)
• User Lifecycle Management (signup, auth, profile, password change)
• Document Tokenization Layer (FileTokens, SAS URI retrieval)
• Client Application Configuration (Auth0, telemetry, reCAPTCHA)

2. Attack Surface Analysis: 184 API Endpoints

2.1 Service Inventory

2.2 High-Risk Endpoint Groups

The following endpoint clusters carry the highest exploitation potential for the BFSI sector:

2.3 Anonymous Proxy Pattern Analysis

The AnonymousProxy service description states its purpose explicitly: "Below APIs are used by anonymous user to submit and read claims." This service is the platform's unauthenticated ingress surface:

The presence of a reCAPTCHA validation endpoint (validaterecaptcha) alongside directly reachable signup, passwordchange, and assignment endpoints indicates the CAPTCHA gate is implemented as a callable API rather than enforced at the proxy layer — a pattern historically bypassed by calling downstream operations directly.

3. Client-Side Configuration Exposure

3.1 FNOL Users UI Configuration Findings

The client application configuration artifact (fnol_users_ui_config.json) exposes the platform's complete runtime topology and embedded credentials. This artifact is served to the browser, making the following data publicly retrievable by any visitor:

3.2 Runtime Topology Disclosure

The configuration artifact enumerates the complete microservice topology, including command and read API pairs, revealing the internal network architecture to any unauthenticated visitor:

Beyond the five swagger-harvested services, the topology discloses six additional platform services not covered by recovered API definitions: whitelabel (read+command), communicationmanagement (read+command), and the CDN content management tier. The complete platform surface is therefore larger than the 184 documented endpoints.

4. Data Layer Analysis: Tokenization Schema

4.1 FileTokens Table

The FileTokens schema implements SAS-URI document tokenization with an integrated security assessment pipeline:

4.2 Token Retrieval Procedure

The companion stored procedure (usp_Fabric_FileTokens_GetToken) governs token retrieval. Tokenized document access flows through blob SAS retrieval endpoints (getblobsasuri) present in three services — including the anonymous proxy. Key controls to verify in remediation:

• SAS URI expiry — tokens must be short-lived and single-purpose
• Scope restriction — SAS URIs should grant read-only, per-blob access
• Active flag enforcement — IsActive gating on token consumption
• Security pipeline — SecurityResult/SecurityMessage columns confirm malware scanning is integrated; verify enforcement prevents download on non-clean verdicts

5. Operational Intelligence Leakage

5.1 Culture Registry Leak

The culture registry response (cultures_leak.json) exposes 23 records with identity metadata:

5.2 Heartbeat Stack Trace Disclosure

The heartbeat handler exception artifact (user_read_heartbeat_stacktrace.json) discloses internal engineering details via a System.NotImplementedException propagated by HeartbeatAzureHandler:

Disclosed intelligence:

• Internal namespace structure — Crawford.FNOL.User.Read.Handlers / Contracts.Requests.HeartbeatAzureQuery
• MediatR pipeline — request-handler wrapper implementation confirms CQRS/MediatR architecture
• CI/CD build path — /home/vsts/work/1/s/ identifies Azure DevOps (VSTS) hosted build agents and the agent checkout layout
• Unfinished component — Azure heartbeat endpoint is unimplemented (line 33), despite being published in production-facing service definitions

6. On-Premises Database & Warehouse Inventory

6.1 Production On-Premises Database Inventory

Static review of the deployment artifacts (Renovo.Api/appsettings.json, Renovo.Infrastructure/DataMigrations/CrawfordDbContext.cs, and Crawford.Fabric test projects) reveals the platform's data tier is SQL Server-based on the internal network — no Snowflake was found in any artifact. The production inventory:

6.2 Hybrid Auth Pattern on a Single Instance

The on-prem SQL instance DKAtlDBsVCMS004 hosts both authentication schemas simultaneously:

This is a two-tier secrets pattern on one instance: the core application authenticates via domain identity (no passwords in config), while the CMS and HCM layers use stored SQL credentials — all co-located in the same Renovo.Api/appsettings.json production configuration. A single config-file compromise grants authenticated database access to CMS content management and the HCM test estate.

6.3 Warehouse Pattern: SQL Server, Not Snowflake

The test project Crawford.Fabric.DataTeam.Tests.Test.Downstream.UK references a Warehouse database via stored procedures:

• Procedures executed as exec [Warehouse].[dbo].[proc_name] (e.g., @warehouseProcName)
• Connection strings passed at runtime as conn_Str_Ware parameters — not hardcoded in test code
• Target tables include TBL_RS_DivisionalWIP (divisional work-in-progress data)

Exhaustive grep of renovo-api-core, Crawford.Fabric, and the test projects returned zero results for snowflake, snowflakecomputing, or SNOWFLAKE. The data warehouse is entirely SQL Server-based on the internal network — an on-premises estate pattern rather than a cloud warehouse deployment.

7. Threat Model

7.1 Crawford FNOL Attack Vectors

8. Regulatory Compliance Mapping (BFSI-Specific)

8.1 Multi-Jurisdictional Compliance Matrix

Conclusion: Security Imperative

Crawford & Company's FNOL platform presents a materially attackable surface that demands immediate remediation. The evidence demonstrates:

1. 184 documented API endpoints across 5 harvested services, plus 6 additional services disclosed in client configuration
2. Unauthenticated claim intake and document access via the anonymous proxy surface
3. Client-side exposure of Auth0 tenant configuration, Google keys, and telemetry instrumentation
4. User enumeration and auth-command attack paths across the user read/command service pair
5. Operational intelligence leakage via culture registry metadata and exception telemetry
6. On-premises SQL Server estate with hybrid-auth credential exposure — SQL-auth creds committed in production configuration, Windows Integrated + SQL Auth co-located on one instance

stage-x.space FDE AI security provides the remediation path: continuous external attack-surface monitoring, automated credential-hygiene enforcement (including on-prem DB credentials), drift detection between published and actual API exposure, and BFSIboard-aligned compliance automation. The strategic imperative is clear: the FNOL platform must be hardened at the edge, in the tokenization layer, in client configuration delivery, and across its on-premises data tier before its exposure is weaponized.

This research was conducted using local-first semantic layer technology (DuckDB + Kuzu) with zero external data egress from the analysis environment. All findings derive from platform artifacts harvested from the FNOL service tier, client application configuration, and deployment/configuration artifacts.