1. You receive this alert:

"Multiple Failed Logins Detected"
User: john.smith
Source IP: 185.x.x.x
25 failed attempts in 5 minutes

What will you do?

Answer:

I would first validate the alert and investigate:

1. Check the username and affected system.
2. Check the source IP reputation.
3. Check IP geolocation.
4. Determine whether the IP belongs to VPN/proxy infrastructure.
5. Check whether other users were targeted from the same IP.
6. Check whether a successful login occurred after the failures.
7. Check the authentication method and MFA status.
8. Review the user's normal login behavior.
9. Search for post-authentication activity.

If multiple accounts are targeted, I would consider password spraying. If one account is repeatedly targeted with many passwords, I would consider brute force.

2. What if the same IP has 100 failed logins against 20 users?

Answer:

I would suspect password spraying.

I would search the SIEM for:

Source IP → Multiple usernames → Failed authentication

Then I would check whether any of those accounts had a successful login from the same IP.

If there is a successful authentication, I would investigate that account immediately for possible compromise and escalate according to the SOP.

3. You see:

4625 - Failed Logon 4625 - Failed Logon 4625 - Failed Logon 4624 - Successful Logon

What does this indicate?

Answer:

It could indicate a brute-force attack or password spraying followed by successful authentication.

However, I would not immediately declare it malicious. I would investigate the source IP, account, logon type, device, time, user behavior and subsequent activity before determining TP or FP.

4. A user successfully logged in from India at 10:00 and the same account logged in from the UK at 10:05. What do you do?

Answer:

I would investigate it as a potential impossible-travel or account-compromise alert.

I would check:

• Source IPs
• Geo-location
• VPN/proxy/TOR usage
• Device information
• User agent
• MFA events
• Previous login history
• Other users using the same IP
• Activity after both logins

If one IP belongs to a corporate VPN, the alert may be legitimate.

5. EDR shows:

WINWORD.EXE └── powershell.exe └── cmd.exe └── malicious.exe

What do you think?

Answer:

This is highly suspicious because a Microsoft Word process spawning PowerShell and then executing another command interpreter can indicate malicious document execution.

I would investigate:

• PowerShell command line
• Parent-child relationship
• Malicious executable
• File hash
• File location
• Network connections
• User
• Download source
• Persistence
• Other endpoints with the same IOC

I would map the activity to relevant MITRE ATT&CK techniques and escalate if confirmed malicious.

6. PowerShell command is:

powershell.exe -enc SQBFAFgA...

What would you do?

Answer:

The -enc or -EncodedCommand parameter means the PowerShell command is Base64 encoded.

I would decode it in a safe analysis environment and investigate what the command does.

I would also check:

• Parent process
• User
• Endpoint
• Download URLs/IPs
• File hashes
• Network connections
• Persistence
• Related alerts

Encoded PowerShell is not automatically malicious, but it is a strong indicator requiring investigation.

7. A user downloads an .exe file from an email. What do you check?

Answer:

I would check:

1. Sender.
2. Sender domain.
3. Email headers.
4. SPF/DKIM/DMARC.
5. Attachment name.
6. File hash.
7. VirusTotal or other approved threat-intelligence sources.
8. Whether the user executed it.
9. EDR process activity.
10. Network connections after execution.
11. Whether other employees received the same email.

8. VirusTotal says a file has only 2/70 detections. Is it malicious?

Answer:

Not necessarily.

I would not rely only on the detection count. I would examine:

• File behavior
• Hash reputation
• Digital signature
• File origin
• Parent process
• Network activity
• Sandbox results
• EDR telemetry
• Whether the file is expected in the environment

A low detection score doesn't automatically mean the file is safe.

9. SentinelOne detects malware but automatically quarantines it. Is the incident closed?

Answer:

No.

Quarantine only indicates that the detected file was contained. I would still investigate whether the malware executed before quarantine, whether persistence was established, whether additional files were created, and whether there was network communication.

I would also search for the same hash or IOC across the environment.

10. An endpoint is communicating with:

185.x.x.x:443

Is this malicious?

Answer:

Not based on the port alone.

Port 443 normally represents HTTPS, so I would investigate:

• Destination IP reputation
• Domain
• TLS information where available
• Process responsible
• Connection frequency
• Beaconing pattern
• User
• Endpoint
• Previous communication
• Threat-intelligence results

A malicious C2 server can use port 443 to blend into normal HTTPS traffic.

SIEM Hands-on

11. How would you investigate a suspicious IP in Splunk?

Answer:

I would search the IP across relevant indexes and sourcetypes.

For example:

index=* "185.x.x.x"

Then narrow it down based on:

Source IP Destination IP Username Hostname Timestamp Action URL Process

I would determine whether the IP appears in authentication, firewall, proxy, DNS, EDR or application logs.

12. How would you find all users targeted by an IP?

Answer:

Conceptually, I would search authentication logs for the source IP and extract the usernames.

For example:

index=* src_ip="185.x.x.x" | stats count by user

Then I would investigate the accounts with successful authentication separately.

13. How would you investigate an IOC across the environment?

Answer:

I would search the IOC across:

SIEM + EDR + DNS + Proxy + Firewall + Email + Cloud logs

For example, for a malicious IP:

IP → DNS activity IP → Firewall connections IP → Proxy activity IP → EDR network connections IP → Authentication logs

The objective is to determine scope and impact, not just confirm that the IOC exists.

14. You find a malicious hash on one endpoint. What next?

Answer:

I would search the hash across the entire environment.

If it appears on multiple endpoints, I would determine:

• Number of affected systems
• Users involved
• First seen / last seen
• Whether execution occurred
• Network communication
• Persistence
• Common delivery mechanism

This helps determine the scope of the incident.

Windows Hands-on

15. Event ID 4720 appears. What do you investigate?

Answer:

4720 indicates user account creation.

I would check:

• Who created the account?
• Which account was created?
• When?
• On which system?
• Was the creator authorized?
• What privileges were assigned?
• Was the account subsequently used?
• Were there related 4728/4732 events?
• Was the account added to a privileged group?

16. Event ID 1102 appears. What do you do?

Answer:

Event ID 1102 indicates the Windows Security audit log was cleared.

I would investigate:

• Who cleared the log?
• When?
• Which host?
• Was it an administrator?
• What events occurred immediately before the clearing?
• Were there suspicious logons or process executions?
• Are there other indicators of compromise?

Because attackers can clear logs to remove evidence, I would treat unexpected 1102 events seriously.

17. You see:

cmd.exe → powershell.exe → certutil.exe

What would you investigate?

Answer:

I would investigate the command line and purpose of certutil.exe.

certutil is a legitimate Windows utility but can potentially be abused for downloading or decoding files.

I would check:

• Full command line
• Parent process
• Downloaded file
• Destination
• File hash
• Network connection
• User
• Endpoint
• Subsequent execution

Phishing Hands-on

18. You receive a phishing alert. What is your investigation process?

Answer:

My process would be:

Email → Sender → Header → URL → Attachment → User activity → Endpoint → IOC search → Scope → Containment → Escalation

I would determine whether the user clicked the URL or opened the attachment because that changes the severity and investigation scope.

19. A malicious email was sent to 500 employees. What do you do?

Answer:

I would determine:

• How many received it?
• How many opened it?
• How many clicked?
• Who submitted credentials?
• Whether attachments were executed.
• Whether the same URL/domain appears elsewhere.

I would identify the affected users and coordinate removal/blocking of the malicious email, URL, domain or attachment according to the organization's procedures.

Cloud / Identity Hands-on

20. AWS GuardDuty reports suspicious activity. What do you check?

Answer:

I would check:

• Finding type
• Account
• Region
• Resource
• Source IP
• Destination
• Timestamp
• IAM identity
• API calls
• CloudTrail events
• Whether the activity is expected

Then I would determine whether the AWS resource or credentials may be compromised.

21. An AWS access key is used from an unusual country. What do you do?

Answer:

I would investigate:

1. Access key/user.
2. Source IP.
3. Geo-location.
4. CloudTrail activity.
5. API calls performed.
6. Resources accessed.
7. Whether MFA was involved.
8. Historical usage of the key.
9. Whether the IP belongs to VPN/cloud infrastructure.

If unauthorized activity is confirmed, I would follow the organization's credential containment procedure.

Advanced L1 Scenario Questions

22. You have this process tree:

explorer.exe └── powershell.exe └── rundll32.exe └── suspicious.dll

Question: What concerns you?

Answer:

The execution chain is suspicious because PowerShell launches rundll32.exe, which executes a DLL. rundll32.exe is a legitimate Windows utility but can be abused for execution.

I would investigate the command line, DLL location, hash, signature, parent process, network activity and persistence.

23. An alert says "Possible C2 Beaconing." What do you check?

Answer:

I would look for:

• Repeated connections
• Regular time intervals
• Destination IP/domain
• Port
• DNS activity
• Process responsible
• Connection duration
• Data transferred
• TLS/HTTP characteristics
• Threat-intelligence reputation

A periodic connection pattern from an unusual process to a suspicious external destination could indicate C2 activity.

24. A detection fires, but the user says the activity was legitimate. Do you close it?

Answer:

No. User confirmation is useful but not sufficient by itself.

I would validate the claim against logs, endpoint telemetry, timestamps, source IP, command line and expected administrative activity.

If the evidence confirms legitimate activity, I can classify it as a false positive according to the organization's process.

25. You have 500 alerts and only 30 minutes before SLA breach. What do you do?

Answer:

I would prioritize rather than process them randomly.

My priority would be:

Critical severity → Confirmed malicious activity → Critical assets → Privileged accounts → Active compromise → High-confidence detections → Lower-risk alerts

I would also follow the organization's escalation and SLA procedures and ensure that high-risk cases are handed over properly.

The most important hands-on question

26. "I give you this alert. Show me exactly how you would investigate it."

This is where many candidates struggle.

Your answer should follow this structure:

1. Understand the alert — What triggered it?

2. Identify entities — User, host, IP, domain, hash, process.

3. Validate — Is the activity expected?

4. Enrich — Check reputation and threat intelligence.

5. Correlate — Search SIEM/EDR and related logs.

6. Determine scope — Is it only one host/user or multiple?

7. Determine TP/FP — Based on evidence.

8. Contain/Escalate — Follow the SOP and permissions.

9. Document — Record evidence, timeline, actions and conclusion.