Triage an alert IP
Corroborate a local alert with observed activity and confidence.
Prerequisites and plan required
Start with an IP from your own alert and permission to investigate it. Sign in to an organization in the Console. Public and Researcher organizations can perform five limited Console lookups per UTC day; Professional and Enterprise unlock the full evidence view. The API requires a Professional or Enterprise bearer key with events scope. A Console session alone is not an API credential.
Expected result: a recorded verdict, accessible observation window and defensible next action that you can compare with local evidence. A lookup reports what Mothlight observed, not whether your system was compromised.
1. Look up the address
Open Console → Lookup, enter the public IPv4 or IPv6 address from your alert, and select Look up. Reserved and private addresses are rejected. Do not substitute an unrelated public address just to get a result. You can also enter an ASN for network context, but an ASN describes shared network activity, not every member address.
For a collector, call GET /api/v1/lookup/ip/{ip}, replacing YOUR_PUBLIC_IP locally with the alert address:
curl --fail-with-body \
-H "Authorization: Bearer YOUR_API_KEY" \
'https://mothlight.ai/api/v1/lookup/ip/YOUR_PUBLIC_IP'2. Read verdict, confidence and action together
Inspect verdict, confidence, suggested_action and action_reason in a full result. Confidence ranges from 0 to 100 and describes observation evidence; it is not a probability that your alert is malicious. Read evidence_classes, first_seen, last_seen, event counts and the response caveats before deciding what to do.
A block_candidate suggestion calls for review of a time-limited block under your policy. A challenge suggestion supports additional verification. An observe suggestion calls for corroboration. None should bypass your own incident process. Shared hosting, proxies, VPNs and reassigned addresses can carry unrelated users. A positive observation does not identify a person or prove compromise of your environment.
3. Check the window and local context
The lookup history is capped at 30 days, including Enterprise. Professional applies a 15-minute delay; Enterprise has no minimum event delay. Read window.since, window.until and window.delay_minutes rather than assuming the result includes the newest activity. Daily counts show recurrence; protocol and category summaries describe observed behavior. SCN means Scanner and EXP means Exploit bot; use the glossary for other labels.
Compare that window with your alert's timestamp, destination service and local authentication or exploit evidence. In the paid Console result, use Open in Events for deeper review. The evidence detail uses at most the newest 5,000 events, while totals cover the full lookup window; a summary should preserve that distinction.
4. Record a reversible decision
Save the UTC investigation time, queried address, observation window, verdict and reason in your approved case system. Limit access to copied JSON. If you apply a local response, record an expiry and rollback owner. For a maintained appliance list, use the firewall EDL guide. For recurring correlation, use SIEM enrichment.
Troubleshooting
Not seen means unknown, never safe: coverage, history and delay can explain an absence. A limited result on a free plan is expected and does not contain full confidence or evidence. A 400 usually means malformed or reserved input; 401 means a missing or invalid API key; 403 means insufficient plan/scope; 429 means a quota or rate limit. API requests consume one request and one row. Review FAQ before retrying repeatedly, and keep the absence caveat in any downstream report.