5 Portfolio Projects to Build While Studying Security+

Build something while you study for Security+. A packet capture, a tested firewall rule or a short log investigation gives you an example when someone asks how you have applied what you learned.

You do not need a home lab. One virtual machine is enough for several of these projects; the firewall exercise needs two. Use your systems create test accounts and work with dummy files. Before changing a VM take a snapshot so you can return to its state.

The goal is to produce evidence you can explain: what you configured how you tested it what happened and what you still could not confirm. These five projects give you a place to start.

1. Analyze a DNS Lookup in Wireshark

The task: Capture a DNS request and explain its response.

DNS translates names into records that applications use to find services. Reading about that process is useful. Finding the request and response in a packet capture makes you work through the details.

Open Wireshark, select your network interface and start a capture. Generate a DNS lookup for example.com then stop recording. Enter 'dns' in the display filter to focus on DNS packets. A display filter changes which packets appear on screen; it does not remove packets from the capture.

Find one query and its matching response. Identify:

The name being requested and the query type.

The addresses of the client and DNS server.

The transaction ID used to help match the exchange.

The returned. Response code.

Keep your explanation tied to what you captured. If you requested an A record explain the IPv4 answer you received. If the response reports an error describe that result of replacing it with an ideal example.

An empty display is also worth investigating. Check the selected interface. How you generated the lookup. Cached answers or encrypted DNS may affect what appears in the capture.

What to publish: An screenshot and a short explanation of the exchange. Explain how you identified the response and what the answer means. Review the capture for traffic and sensitive information before sharing it.

This project gives you practice with network analysis, protocol behavior and explaining evidence.

2. Harden a Virtual Machine and Verify the Changes

The task: Improve a VM's security settings. Test the result.

Choose a Windows or Linux VM. Before changing anything record its operating‑system version, update status, accounts, firewall state and listening services. This becomes your baseline.

Select a few changes you understand. You might install updates create an account for daily use enable the host firewall or disable a service that your lab does not need.

Avoid copying a hardening checklist without checking what each setting does. A change that blocks your intended workflow needs investigation even if it appears in a security guide.

For each change answer three questions:

1. What exposure or unnecessary privilege am I addressing?

2. What setting did I change?

3. How did I check that the change worked?

If you disable a service confirm that it stopped and that the functions you still need work. If you create an account test whether an administrative task requires elevation. After installing updates check their status. Complete any required restart.

Record any result. Perhaps a service you thought was unnecessary supports an application you use. Explain how you identified the dependency and whether you restored the setting.

What to publish: A before‑and‑after configuration record, selected screenshots and a brief rollback procedure. State the limits of your checks. Completing a few hardening steps does not establish that a machine is secure against every threat.

The useful part of this project is the connection between a security decision and its verified effect.

3. Test a Firewall Rule

The task: Control access to a service between two lab machines.

Place two VMs on a virtual network. Use one, as a client and the other as a server running a web service. Record their addresses and the service's listening port.

Confirm that the client can access the service before adding a blocking rule. Without this baseline a failed connection could simply mean that the server was never reachable.

Create a rule on the server that blocks the client's connection to that service. Repeat the request then remove the temporary rule and try again.

Your test should cover three states:

Before the rule: Confirm whether the request succeeds.

With the rule active: Record whether the request is blocked.

After removing the rule: Check whether access returns.

If the results differ from your expectations inspect the source address, destination port, protocol and applicable firewall settings. Confirm that the service is still running. Check firewall logs where

Use the application request as your test. A ping checks ICMP traffic so its result does not establish whether a particular TCP service is accessible.

What to publish: A network diagram, the rule configuration and the results of all three tests. Explain what the rule permits or blocks and why its scope fits the task.

A screenshot of a rule proves that you configured something. The connection tests provide evidence about what that configuration did.

4. Investigate Failed Logins in Windows

The task: Build a timeline from a controlled login exercise.

Create a test account in a Windows VM. Check the account lockout policy first then enable success and failure auditing for logon events if it is not already configured.

Generate a number of incorrect password attempts staying below the lockout threshold. Follow them with a sign‑in. Note the times and the method you used to sign in.

Open Event. Inspect the Security log. Microsoft documents event 4625 for a failed logon and event 4624 for a logon.

Find entries associated with your test account. Review the timestamps, logon type and available failure details. Check source‑address information when present. Do not assume every event contains it.

Build a timeline using the events you can connect to the exercise. Be careful with successful‑logon events: Windows also creates sessions for activity other than someone typing a password at the sign‑in screen.

Separate observation from interpretation. Several failed attempts followed by a success may warrant investigation. That pattern alone does not establish that an attacker accessed the account.

In this exercise you generated the activity yourself. Explain what you would need to check in a case, such as whether the account owner recognized the activity and what happened after the successful login.

What to publish: A one‑page investigation note covering the exercise relevant events, your assessment and unanswered questions. Label it as a simulation. Remove unnecessary account or device identifiers.

This project lets you practice reporting without claiming an incident occurred when the evidence does not support that conclusion.

5. Restore a Backup and Check File Integrity

The task: Recover test files. Verify their contents.

Create a folder containing dummy documents. Record the filenames. Calculate SHA‑256 hashes of the originals. Back up the folder to a location using a method you can describe and repeat.

Once you have confirmed that the backup exists delete the working copies of those test files. Restore them calculate their hashes and compare the results with your original record.

Matching hashes help verify that the restored contents are unchanged. Open the files well. Record how long the restoration took and any step that required troubleshooting.

Describe the limits of your arrangement. A copy on the physical drive would not survive that drive failing. A backup that remains writable, from the account could be changed or deleted.

You can extend the exercise by editing one test document after the backup. Restore the version and identify which changes are missing. This gives you a way to discuss how backup timing affects the amount of work you might lose.

What to publish: The backup method, restoration steps, hash comparisons, recovery time and known limitations. Record the outcome you observed including any failed restoration attempt and its cause.

A backup job reporting success is information. Recovering files with the expected contents gives you stronger evidence that the process worked.

Present Your Work

I think you should give each project its folder or page. Write down the goal, the environment, the steps the evidence and an explanation of the result. Record the software versions and the date of testing so readers know the context.

Choose screenshots that support a point. Add captions that explain what to inspect. Keep passwords, tokens, personal files and unrelated network traffic out of uploads.

On your resume label these as lab projects. Describe the work you completed and can explain without rereading the tutorial. A statement about configuring a rule and verifying its behavior is more useful, than a claim that you secured an entire network.

Start with one project. Finish the test check your evidence and write down what happened before you open the tutorial.