What to send your security provider when you report suspicious activity

TL;DR — When you report something odd to your security provider, send the exact time, what you saw, who was affected, the full URL or email details, screenshots, and any raw logs or headers you can export. The single biggest fix is to stop sending vague reports like "the site looked hacked" and instead send a complete evidence bundle in one message. Reading time: ~5 min

Goal

By the end of this guide, you will have a complete incident report package your security provider can act on immediately: a short summary, exact timestamps, affected users or systems, screenshots, URLs, email headers if relevant, and exported logs or event details.

Prerequisites

• Your security provider's support email address, portal, or ticket form
• Access to the affected system's dashboard or admin area
• A way to take screenshots on your device
• The exact date, time, and timezone when the issue happened
• The affected website URL, application page, email message, user account, device, or IP address (internet address) if known
• If email is involved: access to the original email in your mail app
• If login activity is involved: access to your identity provider dashboard (login system), VPN dashboard, or app audit log if available
• If web traffic is involved: access to your CDN/WAF dashboard (content delivery network / web application firewall) or hosting logs if available
• Optional command-line access for header checks; if you have it, use:

curl --version

• Optional terminal tools for DNS or IP checks; if you have them, use:

nslookup example.com

Steps

Step 1: Write a one-paragraph summary of what happened

Paste this template into your ticket, email, or portal form and replace the bracketed text with your details:

Subject: Suspicious activity report for [company/app/site name]

We observed unusual activity on [system name or URL] on [YYYY-MM-DD] at [HH:MM] [timezone].
What we saw: [one sentence, for example "a successful login from a country we do not operate in" or "users were redirected to an unknown page"].
Who was affected: [usernames, email addresses, teams, or "all visitors"].
Current impact: [cannot log in / suspicious email received / page blocked / no visible impact yet].
Actions already taken: [password reset / session revoked / device disconnected / none].

What you should see when this step succeeds: you have a clear 4-5 line summary with no missing brackets.

Step 2: Add the exact time and timezone

In your report, add a separate line in this exact format:

Event time: 2026-10-30 14:37 America/New_York

If you only know an approximate time, write:

Event time: between 2026-10-30 14:30 and 14:45 America/New_York

What you should see when this step succeeds: your report includes a full date, time, and timezone, not just "this afternoon" or "earlier today".

Step 3: Capture the affected page, message, or alert exactly as shown

Use your device screenshot tool and save files with literal names like these:

2026-10-30-login-alert.png
2026-10-30-blocked-page.png
2026-10-30-suspicious-email.png

If the issue is a web page, include the full browser address bar in the screenshot so the full URL is visible.

If the issue is an app alert, include the alert title, timestamp, and affected username on screen.

What you should see when this step succeeds: you have at least one screenshot where the URL, username, or alert text is readable.

Step 4: Export or copy the raw details from the system that showed the issue

Use the dashboard path that matches what happened:

If your mail app shows a "View original" or "Show source" option, copy the full headers into a text file named:

2026-10-30-email-headers.txt

What you should see when this step succeeds: you have raw event data with timestamps and identifiers, not just a screenshot.

Step 5: Record the exact URL, IP, email subject, or username involved

Add a section to your report in this exact format and fill in only what applies:

Affected URL: https://example.com/account/login
Affected username or email: user@example.com
Source IP seen in logs: 203.0.113.24
Suspicious sender: billing@example-payments.co
Email subject: Urgent invoice overdue
Device or browser shown in logs: Windows / Chrome

If you have shell access and need to capture the current response headers for a suspicious page, run:

curl -I https://example.com/account/login

What you should see when this step succeeds: your report contains exact identifiers your provider can search for in their tools.

Step 6: State what changed right before the issue

Add this block to your report and fill it in literally:

Recent changes in the last 24 hours:
- [no changes] OR
- DNS updated at 2026-10-30 09:10 America/New_York
- New plugin or extension installed: [name]
- Password reset performed for: [user]
- MFA disabled or changed for: [user]
- Firewall rule changed: [rule name]

What you should see when this step succeeds: your report tells the investigator whether this was preceded by a real change or happened unexpectedly.

Step 7: Send the report with attachments in one message

Use your provider's support portal or email address and attach:

- Your summary text
- Screenshots
- Exported logs or copied event details
- Email headers file if email is involved
- Any related error message copied exactly

Use this final closing block:

Please confirm receipt and advise whether you need additional logs, IP blocks, session revocation, password resets, or DNS review.

What you should see when this step succeeds: one complete ticket or email is sent with all evidence attached, instead of multiple partial follow-ups.

Verify it works

Check for these end-to-end results:

• Your sent email or ticket shows attachments and the full written summary
• The message includes an exact timestamp with timezone
• The message includes at least one searchable identifier: URL, username, IP, sender address, or email subject
• The message includes raw evidence where available: headers, logs, audit events, or firewall events
• Your security provider replies with a case number or confirmation instead of first asking "when did this happen?" or "which user was affected?"

If you are using a ticket portal, the ticket should show uploaded files and the full text body within a minute after submission.

Common pitfalls

Sending only a screenshot

Mistake: You send an image of the problem but no timestamp, URL, username, or log details.

Symptom: The provider replies asking basic questions before they can start.

Fix: Add the Step 1 summary plus the Step 5 identifier block in the same message.

Using local time without a timezone

Mistake: You write "happened at 2:30" with no timezone.

Symptom: Investigators search the wrong time window and miss the event.

Fix: Write the time as YYYY-MM-DD HH:MM Region/City, for example 2026-10-30 14:37 America/New_York.

Forwarding a suspicious email instead of sending headers

Mistake: You forward the email normally.

Symptom: Important routing details are stripped or rewritten, so the provider cannot trace the sender path.

Fix: Open the original message and use View original, Show source, or View headers, then attach the full headers as a .txt file.

Omitting what changed before the incident

Mistake: You do not mention a password reset, DNS update, plugin install, or firewall rule change.

Symptom: The provider spends time treating a self-inflicted change like an external attack.

Fix: Add the Step 6 "Recent changes in the last 24 hours" block, even if the answer is no changes.

Sending multiple fragmented updates across email threads

Mistake: The screenshot is in one email, the URL is in another, and the logs are pasted into chat.

Symptom: Evidence gets missed and the investigation starts slowly.

Fix: Put the full summary, identifiers, and attachments into one ticket or one email thread with a single subject line.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.