How to Report Network Security Incidents to a CERT Team: Templates for Vulnerability Exploitation and Intrusions

When a security incident is too large, too coordinated, or too technically complex for a single ISP abuse desk to handle, that is when you need a CERT team. Computer Emergency Response Teams (also called CSIRTs — Computer Security Incident Response Teams) exist at a different level than ISP abuse departments. They do not just take down a single offending IP. They coordinate responses across organizations, analyze attack patterns, issue advisories, and share intelligence that helps entire sectors defend themselves.

If you have ever reported abuse to a hosting provider and felt like you were shouting into the void, a CERT can be the escalation path that actually moves the needle. I have filed reports with national CERTs that resulted in coordinated takedowns spanning multiple countries and providers — something no single abuse desk could achieve alone.

This article is part of my complete guide to reporting IP abuse. Here I focus specifically on when and how to engage CERT teams, with templates for vulnerability exploitation and network intrusion scenarios.

When to Contact a CERT Team

Not every security incident warrants a CERT report. Most routine abuse — spam, individual brute force attempts, single-source scanning — should go directly to the offending ISP or hosting provider. You should escalate to a CERT when the incident meets one or more of these criteria.

Active exploitation of known vulnerabilities. When you detect an attacker actively exploiting a CVE against your infrastructure, especially if the vulnerability is recent and likely affecting other organizations, CERTs need to know. They can issue alerts that reach thousands of defenders simultaneously.

Zero-day discovery. If you have identified a previously unknown vulnerability being exploited in the wild, a CERT is the right place to report it. They have established processes for coordinated vulnerability disclosure and can work with vendors to produce patches before public disclosure.

Coordinated attacks across multiple organizations. When you learn through threat intelligence sharing or industry contacts that the same attacker is hitting multiple targets, a CERT can correlate reports and coordinate a unified response. Individual organizations see fragments — CERTs see the whole picture.

Critical infrastructure incidents. Attacks targeting energy, financial, healthcare, transportation, or government systems often have national security implications. Sector-specific and national CERTs have authority and resources that go far beyond what an ISP can bring to bear.

Incidents spanning multiple countries. When attack traffic originates from several jurisdictions, no single country's law enforcement or ISP can address it alone. CERTs have international cooperation frameworks through organizations like FIRST (Forum of Incident Response and Security Teams) that enable cross-border coordination.

If your incident is a compromised server or DDoS attack from a single source, start with the ISP abuse desk. If that fails or the scope grows, escalate to a CERT.

Types of CERT Teams

CERT teams operate at different levels, and choosing the right one matters for getting an effective response.

National CERTs

These are government-backed teams responsible for cybersecurity at the national level. They handle incidents affecting critical infrastructure, government systems, and coordinate with international partners.

Sector-Specific CERTs

These focus on particular industries where specialized knowledge is essential.

• Financial sector: FS-ISAC (global), which coordinates threat intelligence across banks, insurance companies, and fintech providers
• Healthcare: Health-ISAC, handling incidents involving patient data and medical device vulnerabilities
• Energy: E-ISAC (North America), coordinating grid security and industrial control system incidents
• Research and education: GEANT CERT (Europe), REN-ISAC (US higher education)

Organizational and ISP CERTs

Larger enterprises and ISPs maintain their own CERT teams. These handle internal incidents and serve as the first point of contact before national escalation. If you are reporting abuse originating from a large ISP's network, their internal CERT may be more responsive than the general abuse desk.

What Evidence CERTs Need

CERT reports require more technical depth than a standard ISP abuse report. Where an ISP abuse desk needs enough to identify and act on a single abusive account, CERTs need enough to understand the broader threat, correlate with other reports, and issue actionable intelligence.

Indicators of Compromise (IOCs)

Provide every IOC you have identified. Use IP Location to enrich IP addresses with geolocation and ASN data before including them.

• IP addresses — Source and destination IPs, including any infrastructure used for staging, exfiltration, or command and control
• Domains and URLs — Malicious domains, phishing URLs, C2 domains (see my guide on reporting C2 traffic)
• File hashes — MD5, SHA-1, and SHA-256 hashes of malware samples, dropped payloads, and modified system files
• YARA rules — If you have written detection rules, include them so other organizations can scan their environments

Attack Timeline with TTPs

Map the attack to the MITRE ATT&CK framework where possible. CERTs use ATT&CK as a common language, and mapping your observations to specific techniques makes your report immediately actionable.

Timeline example:
2025-06-05 02:14 UTC — Initial access via CVE-2025-1234 (T1190 - Exploit Public-Facing Application)
2025-06-05 02:17 UTC — Web shell deployed to /var/www/uploads/cmd.php (T1505.003 - Web Shell)
2025-06-05 02:23 UTC — Local privilege escalation via kernel exploit (T1068 - Exploitation for Privilege Escalation)
2025-06-05 02:31 UTC — Credential dumping from /etc/shadow (T1003.008 - /etc/passwd and /etc/shadow)
2025-06-05 02:45 UTC — Lateral movement to database server 10.0.1.50 via SSH (T1021.004 - SSH)
2025-06-05 03:12 UTC — Data exfiltration to 185.234.72.19 over HTTPS (T1041 - Exfiltration Over C2 Channel)

Affected Systems Inventory

List every system that was compromised or targeted, including operating system versions, patch levels, and the services running on them. This helps CERTs assess the vulnerability surface and determine if other organizations running similar configurations are at risk.

Vulnerability Identifiers

Reference specific CVE numbers whenever possible. If the vulnerability does not yet have a CVE, describe it in enough detail that a vendor or coordination center can reproduce and verify it.

Containment Actions Already Taken

CERTs need to know what you have already done — IP blocks applied, systems isolated, credentials rotated, patches deployed. This prevents duplicate effort and helps them understand the current state of the incident.

CERT Incident Report Template

Use this template for reporting network intrusions and active security incidents to a CERT team.

Subject: [CERT Incident Report] Network Intrusion — Active Exploitation of [CVE-ID or description]

CERT Incident Report
=====================

1. REPORTER INFORMATION
   Organization:    [Your organization name]
   Contact Name:    [Your name]
   Email:           [[email protected]]
   Phone:           [Emergency contact number]
   PGP Key ID:      [If available]
   TLP Marking:     TLP:AMBER (or appropriate classification)

2. INCIDENT CLASSIFICATION
   Incident Type:   Network Intrusion / Unauthorized Access
   Severity:        [Critical / High / Medium / Low]
   Status:          [Active / Contained / Resolved]
   First Detected:  [YYYY-MM-DD HH:MM UTC]
   Duration:        [Ongoing since X hours/days OR resolved at timestamp]

3. EXECUTIVE SUMMARY
   [2-3 sentence summary of the incident, its scope, and current impact]

4. INDICATORS OF COMPROMISE
   Source IPs:
     - 185.234.72.19 (AS12345 — Example Hosting, DE)
     - 103.45.67.89 (AS67890 — Cloud Provider, SG)

   Malicious Domains:
     - update-service[.]malicious-domain[.]net (C2)
     - staging[.]attacker-infra[.]com (payload staging)

   File Hashes (SHA-256):
     - a1b2c3d4... — web shell (cmd.php)
     - e5f6g7h8... — privilege escalation exploit
     - i9j0k1l2... — exfiltration tool

   YARA Rules:
     [Attach as separate file or paste inline]

5. ATTACK TIMELINE (MITRE ATT&CK MAPPED)
   [YYYY-MM-DD HH:MM UTC] — [Action] ([ATT&CK Technique ID])
   [YYYY-MM-DD HH:MM UTC] — [Action] ([ATT&CK Technique ID])
   [Add all observed steps]

6. AFFECTED SYSTEMS
   | Hostname     | IP          | OS/Version           | Role            | Status     |
   |------------- |-------------|----------------------|-----------------|------------|
   | web-prod-01  | 10.0.1.10   | Ubuntu 22.04 LTS     | Web server      | Compromised|
   | db-prod-01   | 10.0.1.50   | CentOS 8             | Database        | Compromised|
   | app-staging  | 10.0.2.20   | Debian 12            | App server      | Targeted   |

7. VULNERABILITIES EXPLOITED
   - CVE-2025-XXXXX: [Description, CVSS score, affected software/version]
   - CVE-2025-YYYYY: [Description, CVSS score, affected software/version]

8. CONTAINMENT ACTIONS TAKEN
   - [Action 1 with timestamp]
   - [Action 2 with timestamp]
   - [Action 3 with timestamp]

9. EVIDENCE PRESERVED
   - Full packet captures (PCAP): [size, time range]
   - System images: [list of forensic images]
   - Log files: [types and retention period]

10. REQUESTED ASSISTANCE
    - [Specific asks: threat intel sharing, coordination with other victims,
       vendor notification, law enforcement referral, etc.]

Vulnerability Exploitation Report Template

Use this template when you detect active exploitation of a specific vulnerability, especially if you believe other organizations are being targeted.

Subject: [Vulnerability Exploitation Report] Active Exploitation of CVE-YYYY-NNNNN

Vulnerability Exploitation Report
===================================

1. REPORTER INFORMATION
   Organization:    [Your organization name]
   Contact Name:    [Your name]
   Email:           [[email protected]]
   TLP Marking:     TLP:AMBER

2. VULNERABILITY DETAILS
   CVE ID:          CVE-YYYY-NNNNN
   CVSS Score:      [Score] ([Vector string])
   Affected Software: [Product name, vendor, affected versions]
   Patch Available: [Yes — link to advisory / No — zero-day]

3. EXPLOITATION OBSERVED
   First Seen:      [YYYY-MM-DD HH:MM UTC]
   Attack Vector:   [Network / Adjacent / Local]
   Exploit Method:  [Description of how the vulnerability is being exploited]
   Automation:      [Manual / Semi-automated / Fully automated scanning]

4. ATTACKER INFRASTRUCTURE
   Source IPs:
     - [IP] (AS[Number] — [Provider], [Country])
     - [IP] (AS[Number] — [Provider], [Country])

   Payload Delivery:
     - [URL or domain used to deliver exploit payload]

   Post-Exploitation:
     - [Observed actions after successful exploitation]

5. IMPACT ASSESSMENT
   Systems Affected:   [Number and type]
   Data at Risk:       [Type of data potentially exposed]
   Business Impact:    [Operational, financial, reputational]

6. DETECTION GUIDANCE
   Network Signatures:
     [Snort/Suricata rules or traffic patterns]

   Host Indicators:
     [File paths, registry keys, scheduled tasks, etc.]

   Log Patterns:
     [Specific log entries indicating exploitation]

7. MITIGATION APPLIED
   - [Patches applied, workarounds implemented, compensating controls]

8. RECOMMENDATION
   - [Suggested actions for other organizations running affected software]

How to Find Your CERT

Finding the right CERT to report to depends on your location, sector, and the nature of the incident.

FIRST.org directory. The Forum of Incident Response and Security Teams maintains a global directory of over 700 CERT/CSIRT teams at first.org/members/teams. Search by country, sector, or team name. This is the most comprehensive listing available.

National CERT lookup. Most countries have a designated national CERT. Search for "[your country] CERT" or "[your country] CSIRT" to find it. In the US, report to CISA at us-cert.cisa.gov/report. In the EU, each member state has its own national CERT, plus CERT-EU for EU institutions.

Sector-specific ISACs. If you are in a regulated industry, your sector ISAC (Information Sharing and Analysis Center) likely has an associated CERT function. Check with your industry association or regulator for the appropriate contact.

Your ISP or hosting provider. Larger providers like AWS, Google Cloud, and Microsoft Azure have their own security response teams that can escalate to national CERTs when warranted. Start there if the incident involves their infrastructure.

When in doubt, report to your national CERT. They will route the report to the appropriate team if it falls outside their scope.

What to Expect After Filing

CERT responses differ significantly from ISP abuse desk responses. Understanding the process helps set realistic expectations.

Acknowledgment. Most CERTs acknowledge receipt within 24-48 hours, though critical incidents may get a same-day response. Some national CERTs have 24/7 operations centers for high-severity reports.

Analysis and correlation. Your report will be correlated with other intelligence the CERT has received. They may come back with additional questions, or share (under TLP restrictions) that other organizations have reported similar activity.

Advisory issuance. If the incident reveals a widespread threat, the CERT may issue a public or TLP-restricted advisory. CISA regularly publishes alerts based on aggregated reports from multiple organizations.

Coordination. For multi-organization incidents, the CERT may convene calls or set up secure communication channels between affected parties. This is where CERTs provide unique value that no other entity can replicate.

Remediation guidance. CERTs often provide specific remediation recommendations, especially for vulnerability exploitation scenarios. These may include detection rules, patching guidance, or hardening recommendations.

Timeline variability. Simple reports might be processed in days. Complex incidents involving international coordination can take weeks or months. CERTs prioritize based on severity, scope, and national interest.

Preventing Future Incidents

Reporting is reactive. These practices reduce the likelihood of needing to file CERT reports in the first place.

Maintain a vulnerability management program. Scan your environment regularly and prioritize patching based on active exploitation status, not just CVSS scores. CISA's Known Exploited Vulnerabilities (KEV) catalog is an excellent prioritization resource.

Establish a patch cadence. Critical vulnerabilities with active exploitation should be patched within 24-48 hours. High-severity vulnerabilities within a week. Everything else within your regular patch cycle, typically 30 days.

Subscribe to threat intelligence feeds. Your national CERT likely publishes alerts and IOC feeds. Subscribe to them. Also consider commercial threat intelligence platforms and open-source feeds like the MISP community.

Join an ISAC. Industry-specific information sharing communities provide early warning of threats targeting your sector. Membership often includes access to classified or TLP-restricted briefings.

Practice incident response. Run tabletop exercises that include CERT reporting as a step in your incident response plan. When a real incident hits, you do not want the first time you file a CERT report to be under pressure.