DWIRC:Staff Training/Incident Handling

DarkWorld IRC Staff Training
Module 8: Abuse and Incident Handling

Program	DarkWorld IRC Staff Training Program
Module	8 of 10
Difficulty	Advanced
Estimated study time	4–6 hours
Assessment	Knowledge check, incident simulations, and formal incident report
Prerequisite	Module 7 — IRC Moderation

Module Overview

An incident is an event that threatens or disrupts DarkWorld IRC users, channels, Services, servers, policies, or operations.

Incidents may include:

• Serious harassment.
• Threats or exposure of private information.
• Coordinated flooding or raids.
• Spam across multiple channels.
• Credential phishing.
• Malicious bots.
• Ban evasion.
• Unauthorized relays.
• Services failures.
• Server disconnections.
• Network attacks.
• Compromised accounts.
• Staff misconduct.
• Policy or approval violations.

Incident handling requires more than issuing a kick or ban. Staff must identify the problem, protect users, preserve evidence, coordinate actions, communicate accurately, and review the outcome.

Learning Objectives

After completing this module, the candidate should be able to:

1. Recognize an incident.
2. Classify its urgency and severity.
3. Take safe immediate protective action.
4. Preserve relevant evidence.
5. Separate facts, allegations, and inferences.
6. Protect private and security-sensitive information.
7. Escalate to the correct team.
8. Maintain a clear incident timeline.
9. Avoid conflicting staff actions.
10. Prepare a professional incident report.
11. Hand over an active incident correctly.
12. Close and review an incident.
13. Identify improvements after an incident.

1. What Is an Incident?

An incident is an event requiring coordinated attention because it:

• Causes significant disruption.
• Affects multiple users, channels, or servers.
• Creates a security or privacy risk.
• Requires more authority than ordinary moderation.
• May continue or spread.
• Requires formal documentation.
• Requires coordination between staff teams.
• Could affect trust in the network.

Not every disagreement or minor rule violation is an incident.

Examples of ordinary moderation include:

• A user posting off-topic content.
• A single accidental flood.
• A minor channel-rule violation.
• A routine kick or temporary channel ban.

The matter may become an incident when it is repeated, coordinated, severe, widespread, security-related, or disputed at a high level.

2. Incident Priorities

During an incident, staff should prioritize:

1. Safety – Protect users and prevent immediate harm.
2. Containment – Stop the incident from spreading.
3. Evidence – Preserve enough reliable information.
4. Coordination – Ensure staff actions do not conflict.
5. Recovery – Restore normal service safely.
6. Communication – Provide accurate and approved information.
7. Review – Learn from the incident and improve controls.

Evidence is important, but staff must not allow serious ongoing harm merely to obtain a more complete log.

3. Incident Severity Levels

DarkWorld IRC may classify incidents using four operational levels.

Level	Classification	Examples	General response
Level 1	Low	Minor isolated disruption, first-time low-impact violation	Guidance, warning, routine moderation
Level 2	Moderate	Repeated flooding, ongoing harassment, repeated advertising, limited ban evasion	Contain, document, notify appropriate staff
Level 3	High	Coordinated raid, multi-channel abuse, phishing, serious threats, unauthorized relay campaign	Immediate containment and senior escalation
Level 4	Critical	Network attack, server compromise, staff-account compromise, Services database risk, widespread data exposure	Emergency escalation, incident leadership, controlled recovery

Severity may change as new information becomes available.

A Level 2 incident may become Level 3 if it spreads across channels. A suspected Level 4 incident may be downgraded after investigation.

4. Severity Assessment Factors

Consider:

• Number of users affected.
• Number of channels or servers affected.
• Whether the incident is ongoing.
• Whether automation is involved.
• Whether private information is exposed.
• Whether credentials are compromised.
• Whether infrastructure is affected.
• Whether the conduct is coordinated.
• Whether the actor is evading restrictions.
• Whether staff access is involved.
• Whether normal service is unavailable.
• Whether harm can spread quickly.
• Whether immediate senior intervention is required.

Do not classify an incident based solely on how angry the reporter appears.

5. Incident Response Process

The general process is:

1. Detect or receive the report.
2. Acknowledge the incident.
3. Perform initial assessment.
4. Assign severity.
5. Protect affected users.
6. Contain active harm.
7. Preserve evidence.
8. Notify the correct staff.
9. Assign or identify incident leadership.
10. Investigate within authorization.
11. Restore normal operation.
12. Communicate the outcome appropriately.
13. Close the incident.
14. Perform a post-incident review.

6. Detecting an Incident

Incidents may be detected through:

• User reports.
• Staff observation.
• Server notices.
• Services messages.
• Monitoring systems.
• Bot alerts.
• PolicyServ.
• RelayServ.
• Channel logs.
• Repeated support requests.
• Server or Services failures.
• Unusual connection patterns.

An alert is not always proof of an incident. Staff should verify available information while remaining ready to act if the risk is high.

7. Receiving an Abuse Report

When a user reports abuse:

1. Acknowledge the report.
2. Determine whether harm is still occurring.
3. Ask where and when it happened.
4. Ask which users or channels are involved.
5. Move sensitive evidence to the approved private process.
6. Avoid promising a specific punishment.
7. Preserve the original report.
8. Escalate according to severity.
9. Explain the next available step.

Example:

Thank you for reporting this. Is the behavior still happening? Please provide the channel, approximate time, and nicknames involved. Do not post IP addresses, passwords, or private evidence publicly.

8. Immediate Protective Action

Immediate action may be necessary to:

• Stop active flooding.
• Remove a malicious link.
• Restrict a phishing account.
• Protect a user from repeated harassment.
• Moderate a channel during a raid.
• Remove a malfunctioning bot.
• Stop an unauthorized relay from importing harmful content.
• Prevent further exposure of private information.

The action should:

• Be within the staff member’s authority.
• Target the active harm.
• Minimize impact on legitimate users.
• Be reversible where practical.
• Be documented.
• Be reviewed after the emergency.

A trainee should request assistance immediately when the available response requires higher authority.

9. Incident Leadership

A serious incident should have a clear incident lead.

The incident lead coordinates:

• Priorities.
• Staff assignments.
• Containment actions.
• Evidence collection.
• Internal communication.
• Public updates.
• Recovery decisions.
• Incident closure.
• Post-incident review.

The incident lead should normally be the most appropriate authorized senior staff member—not necessarily the first person who noticed the problem.

Trainees should follow the incident lead’s instructions and report observations clearly.

10. Staff Roles During an Incident

Where enough staff are available, responsibilities may be divided:

Role	Responsibility
Incident lead	Coordinates the overall response
Moderation responder	Applies approved IRC protections
Technical responder	Checks servers, Services, or infrastructure
Evidence recorder	Maintains logs, timestamps, and the timeline
Communications contact	Provides approved user or staff updates
Policy reviewer	Confirms applicable rules and approval status
Liaison	Coordinates with a DarkWorld project or external operator

One person may perform several roles in a small incident, but responsibilities should remain clear.

11. Internal Communication

During an incident:

• Use the approved staff channel or system.
• Keep messages factual and concise.
• State what was observed.
• State what action was taken.
• Include accurate timestamps.
• Avoid speculation presented as fact.
• Avoid posting credentials.
• Avoid duplicating commands.
• Confirm changes made by other staff.
• Identify who is leading the response.

A useful update is:

20:14 UTC — Flooding observed in #Example from six new connections. Channel temporarily set +m. Three targeted bans applied. Network operator assistance requested. No evidence of other affected channels yet.

A poor update is:

We are being destroyed. Ban everyone.

12. Incident Timeline

A timeline records events in chronological order.

Use a consistent timezone, preferably UTC, and state it clearly.

Example:

20:11 UTC — First repeated advertisement observed in #Example.
20:12 UTC — Same content observed in #Help.
20:13 UTC — Formal warning issued.
20:14 UTC — Additional connections joined and began flooding.
20:14 UTC — #Example set +m by StaffNick.
20:15 UTC — Senior network staff notified.
20:17 UTC — Targeted channel bans applied.
20:21 UTC — Flooding stopped.
20:28 UTC — Normal channel modes restored.
20:35 UTC — Evidence and action record completed.

A timeline should record facts and actions, not emotional commentary.

13. Evidence Preservation

Evidence may include:

• Exact IRC messages.
• Timestamps.
• Channel names.
• Nicknames.
• Visible user masks.
• Registered accounts, where authorized.
• Server notices.
• Mode changes.
• Kick and ban reasons.
• Services responses.
• Bot or relay activity.
• Screenshots.
• Client logs.
• Authorized server logs.
• Policy or application records.
• Staff actions.

Evidence Principles

Evidence should be:

• Relevant.
• Preserved in its original form where possible.
• Complete enough to show context.
• Protected from unauthorized access.
• Linked to the incident record.
• Retained according to approved procedures.
• Shared only with people who require access.

14. Evidence Integrity

Staff must not:

• Alter evidence to change its meaning.
• Delete inconvenient staff actions.
• Fabricate messages.
• Remove timestamps.
• Present a partial log as complete.
• Add assumptions to quoted material.
• Share private evidence publicly.
• Collect unrelated user information.
• Access systems beyond their authorization.

If evidence must be redacted for wider sharing:

• Preserve the protected original.
• Mark the copy as redacted.
• Remove only information not required by the audience.
• Do not change the meaning.

15. Facts, Reports, and Inferences

Incident records should distinguish:

Direct Observation

Staff directly observed the user posting the same link four times in #Example.

User Report

The reporting user stated that similar messages were sent privately.

Technical Evidence

Authorized logs show twelve connections within the same time window.

Inference

The matching timing and content suggest coordination, but common control has not yet been confirmed.

Clear wording protects the accuracy of the investigation.

16. Screenshots and Logs

Screenshots can be useful, but they may:

• Omit earlier context.
• Be edited.
• Hide timestamps.
• Exclude relevant users.
• Show only client-rendered information.
• Expose unrelated private conversations.

Logs can also be incomplete or locally edited.

Where possible:

1. Obtain the relevant time range.
2. Preserve surrounding context.
3. Compare user-provided evidence with authorized logs.
4. Record the source.
5. Avoid assuming a screenshot alone proves the entire allegation.
6. Protect unrelated private information.

17. Confidentiality Levels

Incident information may be classified operationally as:

Classification	Example	Intended audience
Public	Approved service-status message	Network users
Internal	Routine staff coordination	Authorized DWIRC staff
Restricted	Abuse evidence and account information	Assigned investigation team
Highly Restricted	Credentials, vulnerabilities, infrastructure details	Specifically authorized senior or technical staff

Not every staff member needs access to every incident detail.

18. Privacy and Data Minimization

Collect only the information required to:

• Understand the incident.
• Protect users.
• Apply policy.
• Support an appeal.
• Perform technical recovery.
• Meet an authorized operational requirement.

Do not collect unrelated personal information “in case it becomes useful.”

Incident reports should avoid unnecessary:

• Full email addresses.
• Unmasked IP addresses.
• Private conversations.
• External account details.
• Personal documents.
• Credentials.
• Information about uninvolved users.

19. Incident Escalation Paths

The appropriate destination depends on the incident.

Incident	Escalation destination
Routine channel problem	Channel founder or authorized channel staff
Network policy violation	Authorized DWIRC staff or policy team
Advertising approval matter	Policy team
Relay or bridge violation	Relay team
NickServ or ChanServ administration	Services staff
Multi-channel abuse	IRC operators or network administration
Server or link problem	IRCd/network operations
Compromised staff account	Senior network management and security responders
Staff misconduct allegation	Appropriate independent senior reviewer
Other DarkWorld project issue	Relevant project team

An incident may require more than one team.

20. Advertising Incidents

For serious or repeated unauthorized advertising:

1. Preserve the exact content and context.
2. Identify channels and recipients.
3. Determine whether private messages were involved.
4. Check the approval system.
5. Identify repeated or coordinated distribution.
6. Contain ongoing spam where authorized.
7. Escalate approval decisions to the policy team.
8. Record any warning or restriction.
9. Monitor for evasion.

Trainees must not change advertising application statuses without authorization.

21. Relay and Bridge Incidents

For relay-related incidents:

1. Identify the relay bot.
2. Identify the DarkWorld channel.
3. Identify the external source where possible.
4. Check registration or approval status.
5. Determine whether the problem is isolated or repeated.
6. Preserve relayed messages.
7. Contact the operator through the approved process.
8. Apply immediate channel protection if necessary.
9. Escalate to the relay team.
10. Record compliance notices and deadlines.
11. Monitor corrective action.

The relay bot may be the delivery mechanism rather than the original author, but its operator remains responsible for compliance.

22. Harassment and Threat Incidents

For serious harassment:

1. Protect the targeted user.
2. Ask whether the behavior is continuing.
3. Preserve relevant evidence.
4. Avoid requiring public disclosure.
5. Identify repeated contact or evasion.
6. Apply authorized restrictions.
7. Escalate credible threats promptly.
8. Avoid promising real-world protection beyond DarkWorld’s capabilities.
9. Provide appropriate emergency guidance when immediate danger is reported.

DarkWorld IRC staff are not law enforcement or emergency services.

If a person appears to face immediate real-world danger, they should be encouraged to contact the appropriate local emergency or law-enforcement service.

23. Doxxing and Private Information Exposure

Doxxing involves exposing private identifying information without authorization.

Possible examples include:

• Home address.
• Telephone number.
• Private email address.
• Government identification.
• Financial details.
• Hidden IP or connection information.
• Private workplace or family information.

Response priorities:

1. Stop further distribution.
2. Avoid repeating the information.
3. Preserve restricted evidence.
4. Remove exposure where technically possible and authorized.
5. Restrict the responsible accounts.
6. Notify senior staff.
7. Inform the affected user appropriately.
8. Review whether any staff or system data was compromised.

24. Credential Phishing

Phishing may involve:

• Fake NickServ messages.
• Fake staff accounts.
• Links to imitation login pages.
• Requests for passwords.
• Claims that users must “verify” through an unofficial bot.
• Malicious files or scripts.

Response:

1. Stop distribution.
2. Warn users through an approved notice.
3. Preserve the sender, content, destination, and time.
4. Identify affected accounts.
5. Advise exposed users to change credentials.
6. Escalate immediately.
7. Avoid opening malicious content on production systems.
8. Record confirmed compromise separately from possible exposure.

25. Coordinated Floods and Raids

A coordinated flood may affect:

• One channel.
• Several channels.
• One IRC server.
• Multiple servers.
• Services.
• Private messages.
• Network connection capacity.

Initial response may include:

• Temporary channel modes.
• Targeted restrictions.
• Requesting IRC operator assistance.
• Reviewing connection patterns.
• Applying approved network protections.
• Keeping public communication brief.
• Recording every emergency change.

Trainees must not make IRCd configuration or firewall changes.

26. Server and Network Incidents

Possible indicators include:

• Many users disconnecting simultaneously.
• A server disappearing from the network.
• Repeated link failures.
• Significant lag.
• Widespread connection failures.
• Unusual server notices.
• Large numbers of automated connections.
• Several servers becoming unreachable.
• TLS problems affecting multiple users.

Trainees should:

1. Record the affected server or service.
2. Record the time and observed symptoms.
3. Determine whether multiple users are affected.
4. Notify authorized network operations.
5. Avoid making unsupported public claims.
6. Avoid confusing a netsplit with a ban.
7. Follow the approved status-message process.

27. Services Incidents

Possible Services incidents include:

• NickServ, ChanServ, or HostServ disconnecting.
• Widespread SASL failures.
• Registered channel status not being restored.
• Unexpected account or channel changes.
• Services impersonation.
• Services database errors.
• Repeated Services reconnects.

During instability:

• Avoid unnecessary ownership changes.
• Avoid telling all users to reset passwords unless compromise is confirmed.
• Record affected Services.
• Notify Services administration.
• Allow synchronization after recovery.
• Verify that channel access and modes are restored correctly.

28. Compromised Staff Accounts

Indicators may include:

• Unexpected operator commands.
• Unusual login location or timing.
• Unauthorized access grants.
• Unexplained configuration changes.
• Staff denial of actions recorded under their account.
• Password or token exposure.
• Impersonation combined with valid privileges.

Response:

1. Notify senior management immediately.
2. Limit the compromised access through authorized procedures.
3. Preserve relevant logs.
4. Do not confront the suspected attacker publicly.
5. Rotate affected credentials.
6. Review other systems using related credentials.
7. Identify actions performed during the compromise.
8. Restore altered settings carefully.
9. Record the complete response.

Trainees must not attempt to access another staff member’s account.

29. Staff Misconduct Incidents

A staff misconduct allegation may include:

• Retaliation.
• Unauthorized access.
• Exposure of private information.
• Abuse of operator commands.
• Favoritism.
• Falsified records.
• Improper account or channel changes.
• Sharing staff information.
• Interference with an investigation.

The case should be:

• Handled confidentially.
• Preserved accurately.
• Assigned to an appropriate independent reviewer.
• Protected from retaliation.
• Separated from unrelated personal disagreements.
• Decided using evidence and policy.

The accused staff member should not be the sole investigator or decision-maker.

30. Public Communication During an Incident

Public communication should be:

• Accurate.
• Brief.
• Approved.
• Free from speculation.
• Free from confidential details.
• Updated when meaningful information changes.

Example:

We are investigating a service disruption affecting some IRC connections. Network staff are working on recovery. Please avoid repeatedly reconnecting and watch the official channel for updates.

Avoid:

The server was hacked.
We know who did it.
All accounts are compromised.
Everything is fixed.

Unless those statements have been confirmed and approved.

31. Incident Handover

If responsibility passes to another staff member, provide:

Incident reference:
Current severity:
Start time:
Current status:
Affected users/channels/servers:
Confirmed facts:
Unverified reports:
Containment actions:
Active restrictions:
Evidence location:
Teams notified:
Pending tasks:
Next review time:
Current incident lead:

The outgoing staff member should confirm that the receiving person accepted the handover.

32. Recovery

Recovery means safely returning the network or channel to normal operation.

Recovery may include:

• Removing temporary emergency modes.
• Reviewing bans.
• Reconnecting Services.
• Restoring channel access.
• Correcting account settings.
• Re-enabling approved relays.
• Updating status messages.
• Confirming server synchronization.
• Verifying that abuse has stopped.
• Monitoring for recurrence.

Recovery should not begin blindly. Confirm that removing protection will not immediately restart the incident.

33. Closing an Incident

An incident may be closed when:

• Active harm has stopped.
• Necessary restrictions are in place.
• Affected services are stable.
• Required evidence is preserved.
• Users or teams have received appropriate updates.
• Pending actions have owners.
• The final report is complete.
• Review requirements are identified.

Closing an incident does not necessarily mean all long-term work is finished.

Follow-up tasks may remain open.

34. Post-Incident Review

A post-incident review should ask:

• What happened?
• When was it detected?
• What was the impact?
• What worked well?
• What delayed the response?
• Were actions proportionate?
• Were innocent users affected?
• Were records complete?
• Were policies clear?
• Did staff communication work?
• Were tools or bots reliable?
• What documentation should change?
• What technical controls should improve?
• Who owns each follow-up action?

The purpose is improvement and accountability, not personal blame.

35. Incident Report Template

DARKWORLD IRC INCIDENT REPORT

Case reference:
Incident title:
Date:
Timezone:
Reported by:
Incident lead:
Severity:
Current status:

1. Summary
Brief description of the incident.

2. Scope
Affected users:
Affected channels:
Affected servers:
Affected Services:
Affected projects:

3. Timeline
Time — Event or action
Time — Event or action

4. Confirmed Facts
List facts supported by evidence.

5. User or Staff Reports
List relevant claims not directly observed.

6. Inferences and Unknowns
Clearly identify conclusions and unanswered questions.

7. Evidence
Evidence type:
Source:
Location:
Access classification:

8. Immediate Actions
Action:
Performed by:
Time:
Reason:

9. Restrictions Applied
Restriction:
Target:
Scope:
Duration:
Review date:

10. Communications
Internal notices:
Public notices:
Affected-user communication:

11. Escalation
Teams notified:
Time notified:
Response received:

12. Recovery
Services restored:
Modes restored:
Restrictions reviewed:
Verification performed:

13. Impact
Users affected:
Service interruption:
Innocent users affected:
Other consequences:

14. Final Outcome
Resolution:
Remaining risks:
Open follow-up tasks:

15. Review
What worked:
What did not work:
Required improvements:
Responsible person:
Target date:

36. Practical Exercises

Exercise 1: Severity Classification

Classify each simulated case:

• One accidental repeated message.
• Repeated private-message advertising.
• A coordinated raid across three channels.
• A fake NickServ collecting passwords.
• A suspected compromised Services Administrator account.
• A persistent server-link failure.

Explain the reason for each classification.

Exercise 2: Incident Timeline

Using trainer-provided logs:

• Convert events into UTC.
• Arrange them chronologically.
• Separate user actions from staff actions.
• Mark unverified reports.
• Identify missing information.

Exercise 3: Confidential Evidence

The trainer provides a simulated report containing:

• A password.
• An IP address.
• A private-message log.
• Unrelated personal information.

The candidate must identify:

• What must be revoked or changed.
• What evidence is relevant.
• What should be redacted.
• Who may receive the restricted original.
• What must not be posted publicly.

Exercise 4: Coordinated Raid

During a simulated raid, the candidate must:

• Identify the incident.
• Notify the trainer acting as incident lead.
• Recommend proportionate containment.
• Record mode changes.
• Preserve relevant evidence.
• Prepare a public status message.
• Restore the channel after authorization.

Exercise 5: Handover

The candidate must hand an active simulated incident to another trainee using the handover template.

The receiving trainee must confirm:

• Current severity.
• Active restrictions.
• Pending actions.
• Evidence location.
• Next review time.

Exercise 6: Post-Incident Review

Prepare a short review identifying:

• What happened.
• What worked.
• What failed.
• Whether innocent users were affected.
• Three specific improvements.
• An owner for each improvement.

37. Practical Scenarios

Scenario 1: Phishing Nickname

A user named `NickServ-Help` messages users asking for passwords.

Recommended response:

Treat it as a high-severity impersonation and phishing incident. Stop ongoing distribution, warn users, preserve evidence, identify exposed accounts, and escalate immediately.

Scenario 2: Netsplit Misidentified as Attack

Many users quit simultaneously from one server.

Recommended response:

Check for a server disconnection or netsplit. Record the affected server and time, consult authorized notices, and avoid claiming an attack without evidence.

Scenario 3: Relay Imports Threats

An approved relay imports repeated threats from a remote user.

Recommended response:

Protect affected users, preserve the relayed messages, identify the relay and external source, contact the relay operator, and escalate to the relay team and senior network staff.

Scenario 4: Staff Credential Leak

An IRC operator accidentally posts an operator password in a restricted channel.

Recommended response:

Treat the credential as compromised even if the channel is restricted. Notify senior staff, rotate the credential, preserve the event record, and review related access.

Scenario 5: Public Doxxing

A user posts another person’s address and telephone number in a public channel.

Recommended response:

Stop further distribution, avoid repeating the information, preserve restricted evidence, remove exposure where authorized, protect the affected user, and escalate immediately.

Scenario 6: Conflicting Staff Actions

One staff member sets a channel to `+m`; another repeatedly removes it during an active raid.

Recommended response:

Establish incident leadership, stop public mode conflict, coordinate in the staff channel, confirm the active protection plan, and review the conflicting actions afterward.

38. Knowledge Check

Answer the following questions in your own words:

1. What makes an event an incident rather than routine moderation?
2. What are the main incident-response priorities?
3. What are the four proposed severity levels?
4. Which factors influence severity?
5. What is the general incident-response process?
6. What should staff ask when receiving an abuse report?
7. When may immediate protective action be taken?
8. What is the role of an incident lead?
9. Why should staff roles be clear during an incident?
10. What makes a useful internal incident update?
11. Why should one consistent timezone be used?
12. What information belongs in an incident timeline?
13. What types of evidence may be relevant?
14. What is evidence integrity?
15. How should redacted evidence be handled?
16. What is the difference between direct observation and inference?
17. Why should screenshots not always be treated as complete proof?
18. What are the proposed confidentiality levels?
19. What is data minimization?
20. Which team should handle an advertising approval violation?
21. Which team should handle relay compliance?
22. How should serious threats be handled?
23. What are the priorities during a doxxing incident?
24. What steps are required during credential phishing?
25. What should trainees do during a network flood?
26. What may indicate a server or Services incident?
27. Why should permanent access changes be avoided during Services instability?
28. How should a compromised staff account be handled?
29. Who should review a staff-misconduct allegation?
30. What makes an appropriate public incident update?
31. What information belongs in a handover?
32. What is required before recovery protections are removed?
33. When may an incident be closed?
34. What is the purpose of a post-incident review?
35. Why must important staff mistakes remain in the record?

39. Written Assignment

Write a formal incident report for the following case:

At 19:05 UTC, users in `#DarkWorld` report private messages from `DarkWorldSecurity` containing a link to a fake account-verification page. At 19:08 UTC, the same nickname begins posting the link in `#Help` and `#Support`. Two users say they entered their NickServ passwords. At 19:10 UTC, several affected accounts reconnect and begin distributing the same message. One trainee publicly announces that “all DarkWorld accounts have been hacked,” although no network compromise has been confirmed.

Your report must include:

• Initial severity.
• Confirmed facts.
• Unverified reports.
• Immediate containment.
• Evidence requirements.
• Credential-response guidance.
• Internal escalation.
• Appropriate public communication.
• Correction of the trainee’s unsupported statement.
• Identification of potentially compromised accounts.
• Recovery steps.
• Follow-up actions.
• Post-incident improvements.

40. Module Completion Requirements

To complete this module, the candidate must:

• Read the complete lesson.
• Complete all six practical exercises.
• Correctly answer at least 27 of the 35 knowledge-check questions.
• Complete the formal written incident report.
• Correctly classify simulated incidents.
• Preserve evidence appropriately.
• Complete a successful incident handover.
• Participate in the raid simulation.
• Demonstrate accurate public communication.
• Receive trainer approval.

41. Trainer Evaluation

Evaluation area	Maximum points
Incident recognition and severity	15
Immediate protection and containment	15
Evidence integrity and privacy	15
Timeline and documentation	15
Escalation and coordination	15
Incident communication	10
Recovery and closure	10
Post-incident review	5
Total	100

Recommended passing score: 75 points.

A candidate should not pass if they:

• Falsify, conceal, or improperly alter evidence.
• Publicly expose confidential information.
• Ignore a compromised staff account.
• Make unsupported public claims during incidents.
• Repeatedly act outside their authority.
• Obstruct an independent staff review.
• Fail to protect users during serious active harm.
• Refuse to document major actions.

42. Quick Incident Checklist

1. What happened?
2. Is it still happening?
3. Who or what is affected?
4. What is the current severity?
5. Is immediate protection required?
6. What action is within my authority?
7. Who is the incident lead?
8. What evidence must be preserved?
9. Is any information confidential?
10. Which team must be notified?
11. What temporary restrictions are active?
12. What can be communicated publicly?
13. What remains unverified?
14. What is required for recovery?
15. Who owns the follow-up actions?
16. When will the incident be reviewed?

43. Next Module

After passing this module, continue to:

Module 9 — IRC Operator Fundamentals

---

Previous: Module 7 — IRC Moderation Program: DarkWorld IRC Staff Training Program Next: Module 9 — IRC Operator Fundamentals