India Threat Tracker

The problem

Most threat reporting is either global and generic, or locked behind a vendor paywall. Very little of it is built for the person defending an Indian bank, running security at an Indian startup, or trying to keep their parents away from a fake challan app.

The signals that matter for India are scattered: CISA's list of exploited vulnerabilities has no idea which vendors are common here, the fake-APK campaigns are written up in one-off vendor blogs, and actor reporting on APT36 or SideCopy rarely comes with anything a defender can deploy.

The India Threat Tracker pulls that into one open, versioned place, and keeps every claim tied to its source.

What it does

The tracker is a data product with a website on top. Everything is in a public GitHub repository as JSON and CSV, validated against a schema on every change, and browsable at sohankanna.com/tracker.

• Exploited vulnerabilities. Every entry on CISA's Known Exploited Vulnerabilities list, enriched with FIRST EPSS scores and an India-relevance tag with the reason for it. A watchlist pulls out the entries that are India-relevant and recent or linked to ransomware.
• Fraud and malware campaigns. The fake-APK, smishing and UPI fraud campaigns targeting Indian users, each with its sources, a confidence rating, an ATT&CK mapping, defensive actions and defanged indicators. Infrastructure that was abused, such as GitHub or Firebase, is listed as context and never as something to block.
• Threat actors. State-nexus groups relevant to India: Transparent Tribe (APT36), SideCopy and the China-nexus RedEcho, plus the India-nexus SideWinder. Reported attribution is kept separate from the tracker's own confidence in the evidence.
• Detections. Five rules for the activity above, each shipped as Sigma, Splunk SPL, Elastic and Wazuh, plus payments-fraud signals for the UPI kill chain.
• A monthly assessment. A short, ranked analyst view of what to pay attention to, with every judgement linked to the evidence behind it.

The tracker's vulnerability explorer: KEV entries filtered for India relevance, with EPSS and ransomware flags

How it's built

A pipeline that never overrides a human

A GitHub Actions job runs twice a day. It fetches the KEV catalogue and EPSS scores, rebuilds every derived file (feeds, indicators, the STIX bundle, the affected-version data), validates them against their schemas, runs the test suite, and only then commits.

The interesting part is what happens when I push a manual edit while the job is running. The job's push is rejected, and instead of rebasing or merging it resets to the new main and rebuilds everything from the upstream data it already fetched. There is no conflict resolution, so no conflict can ever be resolved in the bot's favour. If my edit breaks a schema, the rebuild fails visibly and nothing is pushed. A test simulates exactly this race.

The job also watches its own inputs. If EPSS enrichment fails for part of the catalogue, or coverage drops, the feed is marked as degraded and the website says so, instead of quietly publishing worse data.

Detections tested where they'll actually run

Every rule has positive and negative test events. For the first release, those were run against an emulator of each SIEM's logic. For the second, I installed a real Wazuh 4.14.9 manager in CI and replayed the same events through it as raw logs.

The real engine found three bugs the emulator could not have, because each one lives in how Wazuh decodes a log rather than in the rule:

1. Wazuh's Palo Alto decoder cuts the description field at the first comma, so the PAN-OS rule could never have matched. It now matches the full log.
2. wazuh-logtest never runs the Windows eventchannel decoder, so it cannot test Windows rules at all. Sysmon events are now sent through the manager's queue the way a real agent sends them.
3. The eventchannel decoder doubles backslashes before parsing, which broke the registry path in the DNS-change rule. It now accepts both.

After the fixes, all 29 test events behave as expected, and the validation report lists every event, expected versus observed. Splunk and Elastic are still emulated, and the documentation says so.

An exposure matcher that never sees your data

The Exposure Matcher takes an asset inventory as a CSV and checks it against every exploited CVE, using the affected-version data in the official CVE records. The file is read and matched in the browser; the page downloads two public data files and nothing else, which I verified with a browser test that records every network request.

Vendor version data is messy, and the matcher is built to say so rather than guess. Palo Alto lists hotfixes per maintenance branch. Citrix writes 13.1 < 49.15 to mean builds of 13.1 below 49.15, not versions 13.1 to 49.15. Some records only say "all other versions". So every result is one of three things: an affected version (the record's own data puts your version in range), a candidate (the product matches but the version can't be settled), or insufficient evidence. About 40% of KEV CVEs have version data clean enough for a confident answer, and the page says exactly that.

Exposure Matcher results for the synthetic sample inventory, with priority tiers and the evidence for each match

Intelligence in the formats CTI teams use

Campaigns, actors, indicators, ATT&CK techniques and the assessment are also published as a single STIX 2.1 bundle. Object ids are generated once and committed, so re-importing updates objects instead of duplicating them, and an unchanged feed rebuilds byte-for-byte. The bundle passes the official OASIS validator in CI, and a conversion test with misp-stix (the library MISP uses for STIX import) checks what survives the trip into MISP.

Decisions I'd defend

• Indicators only. No malware samples are hosted, ever, and indicators are defanged on the website.
• No hidden scores. India relevance comes with a reason, and exposure priority tiers are documented rules, not a black box.
• Attribution is reported, not asserted. Actor records carry what the sources say, with my confidence in the evidence kept separate.
• Say what isn't tested. Every capability states its validation level: real SIEM, emulated, or untested.

What's next

• Run the STIX bundle through a live OpenCTI instance and record what survives.
• Validate the Splunk and Elastic versions of the rules against real instances, the way Wazuh was.
• Widen the campaign coverage with community contributions, using the same evidence rules.

Read the full story of the second release in What a Real SIEM Taught My Detection Rules.