Step 1: Map the infrastructure with Nmap
The scope document lists the targets. Now map them technically. Run Nmap against the Docker network to discover what is running on each container beyond the main application ports.
nmap -sV 172.18.0.0/24
The scan reveals more than the three application ports. Each container may expose additional services. The Docker network itself has structure -- Grafana, Loki, and Alloy are on it too. The full service map gives you the infrastructure layout that Tshering could not describe.
Step 2: Assess the Tourism Services Portal
The Tourism Services Portal stores tourist passport numbers, travel dates, and personal information. It is the highest-priority target given the directive's focus on protecting tourist data.
Direct AI to assess the portal on port 3000. Look for common web vulnerabilities -- the search endpoint is a natural starting point. AI commonly generates thorough vulnerability lists but may miss the severity distinction between a finding that exposes tourist PII and one that does not. Check each finding against what is actually at risk.
The portal was built by one vendor using Node.js and Express. The application logs are already flowing to Loki. Every action you take against this portal generates log entries that will matter later when you build detection rules.
Step 3: Assess the Guide Management System
The Guide Management System on port 5000 handles guide licensing and credential verification. A different vendor built it using Python and Flask -- a different technology stack from the tourism portal.
Direct AI to assess this system. The different vendor means different coding patterns, different authentication approaches, and potentially different vulnerability categories. Compare what AI finds here to what it found on the tourism portal. The guide system also has a credential lookup feature worth examining.
AI generates findings across both portals but may not flag the significance of cross-portal differences. Two vendors building two systems means two independent codebases with two separate sets of assumptions about security.
Step 4: Discover the API interconnections
This is the finding that changes the assessment. The three portals are not isolated -- they communicate through internal APIs that were added after the initial builds. These APIs connect the Guide Management System to the Tourism Services Portal's tourist data, and the Internal Operations Platform aggregates from both.
Test the API endpoints between portals. Are the internal API calls authenticated? Can you reach tourist data through the guide system's API connection without credentials? The internal APIs bypassing main authentication is a critical finding because it means compromising one portal gives access to data in another.
AI may test each portal individually without checking the connections between them. The API authentication bypass only surfaces when you test inter-portal communication -- requests that go from one service to another inside the Docker network.
Step 5: Generate attack data with sqlmap
Run sqlmap against the injection points you identified. The exploitation confirms the vulnerability and generates attack data in the logs that you will detect from the other side in later units.
sqlmap -u "http://localhost:3000/search?q=test" --batch
Every SQL injection attempt sqlmap sends is logged by the Tourism Services Portal. Alloy collects those logs and sends them to Loki. This attack data is not just evidence of a vulnerability -- it is the test data for your detection rules. The attacks you run now create the log patterns you will write rules against later.
Step 6: Document the findings
Document at least three findings across the portals. For each finding, note: what it is, which portal it affects, the severity, and whether tourist data is at risk.
The API authentication bypass is the most critical finding. It connects the portals into a single attack surface -- a breach in any one of them can cascade to the others. This is the finding Tshering needs to know about.
Open the living client interface and inform Tshering about the API authentication bypass. She will want to understand the practical impact: can tourist passport data be accessed through this gap? What does "bypass authentication" mean for her portals? Frame the finding in terms she can act on -- which data is at risk, through which path, and what the immediate implication is for directive compliance.
Check: At least three findings documented across the portals. sqlmap output confirms at least one injectable endpoint. The API authentication bypass is identified and documented.