Author: edmalaker

This is a continuation of Phishing Investigations, Part 5.

So, in the last part of the investigation, we ended while I was searching for information about the email addresses sending me the suspicious links to view photos.

I searched each of the 17 email addresses three ways.

First, I searched for each full email address in quotation marks, using this made-up example:

"unknown.sender@example.com"

This search asks whether that exact address has appeared in a publicly indexed source. Finding it would be a useful clue, but it would not prove that the mailbox was genuine or that its apparent owner sent the messages. Email addresses can be copied, spoofed, or connected to compromised accounts.

Next, I searched for the username and organization separately, using a search like this:

"unknown.sender" "example.com"

I used this because exact email addresses are often not indexed, even when a person and organization are public. This loosens the search while still looking for both pieces. It asks, essentially, “Does this username appear to be connected with this organization even if the site does not publish the full email address?” Once again, a match would be a clue, not proof of identity or responsibility.

Finally, I searched the full email address with the word phishing, using a search like this:

"unknown.sender@example.com" phishing

This tests whether someone else has reported that address as abused, compromised, or connected with suspicious email. A result could show that the address had been mentioned before, but I would still need to evaluate the source and consider whether the address had been spoofed or the account compromised.

After applying these searches to all 17 email addresses, I found only one clue: a real name appeared in one of the addresses.

Unfortunately, after checking the public search results associated with that name, including professional-networking and social-media profiles, I did not find any clear evidence that the person sent the emails or was connected with the organization the messages appeared to come from. I did not contact anyone, publish the name, or treat a profile match as proof. I was essentially back at the beginning.

Next, I searched the exact email text without the link to see whether there were any matches. I looked for phrases that included:

• “We’ve been meaning to send these two images way sooner”
• “These pics should ring a bell”

Again, I found nothing.

The next thing I will do is start looking at the organizations and domains tied to the email addresses. In the made-up example above, that would be the example.com part of the address. I will look for credible reports that the domains or organizations have experienced compromised accounts or phishing abuse. Even if I find such reports, they will be leads to examine—not proof that an organization intentionally sent these messages or that the same person was responsible.

We’ll talk about what I find in the next article.

See you next time!

This is a continuation of Phishing Investigations, Part 4.

In this next part of the investigation, I am going to take a look at the timestamps to see if there is a pattern we can identify that might be helpful.

I looked through each of the emails I received. Inside each one was an “On [date/time], John wrote:” line, so I saved and compared those times as well. It is important to note that this line is part of the message body, not a trusted email-header timestamp. The sender can create or change it, which is one reason a repeated difference may be useful as a campaign pattern.

What I Found

In the sample I reviewed, using one consistent timezone:

• The emails arrived every other day, but only Monday through Friday.
• The emails always arrived before 1 p.m.
• The inner quoted timestamp was always two hours and seven minutes earlier than the actual send time.

The repeated timestamp difference may be a fingerprint of automation or a reused template attempting to make each email appear to be a reply to an earlier message. It is a useful clue, but it does not prove how the messages were created.

The arrival times might also point to an interesting clue. Since the messages arrived before 1 p.m. and not on weekends, could that reflect someone’s working hours? Possibly, but it could also result from an automated schedule, batching, or a different timezone. The timing alone does not prove when or where the attacker is working.

Interesting Update

I was going through some of my old records and noticed that I had older messages from “John Doe,” showing that this pattern had been reaching me for quite some time. These messages had the same two-hour-and-seven-minute timestamp difference.

However, the older messages showed a slight difference in how the links were composed. This could mean that the campaign has changed over time, although the link difference alone is not enough to prove that the same operator created every message.

I also received a message using another name familiar to me that followed the same campaign pattern, including the timestamp difference. I am not sure whether the campaign is switching to this new name or will continue using both, but I will keep watching and documenting what appears.

Next, I will look at the sending email addresses, which I had planned to do this time before the timestamp pattern caught my attention.

See you next time!

This is a continuation of Phishing Investigations, Part 3. If you are new here, you can start at the beginning.

Researching the email links

When I analyzed each of the phishing emails in my folder last time, one of the things I noticed was that every email contained a link I was supposed to follow to “view the pictures” offered in the subject. In every case, the link was unique and contained a unique domain name. As I wrapped up the last article, I decided to research those links to see what I could find.

To begin my research, I used three free websites that are helpful for this type of work:

• urlscan.io
• ICANN Lookup
• VirusTotal

For each email, I checked the link and the domain extracted from it on all three websites. I did not open the suspicious links directly in my browser, and I am not sharing the real links or domains here. Full phishing URLs can contain personal or victim-specific tracking information. It is also important to know whether a service is only searching existing records or submitting a new public scan before entering a suspicious URL.

Each one returned no useful results:

• No current DNS resolution
• No useful public ICANN/RDAP record
• No meaningful VirusTotal history
• No usable urlscan history
• No meaningful search-engine footprint

My working theory is that the campaign may use short-lived, disposable web infrastructure. Each message uses a unique lure domain, and the domains were already non-resolving by the time I checked them, leaving no useful public DNS, registration, scanning, or indexed footprint that I could find.

However, the missing results do not prove that theory. Public tools do not contain everything, registration information can be hidden or unavailable, and a domain might never have been scanned before it stopped resolving. The safest conclusion is simply that I found no useful public record when I checked.

Unfortunately, that does not give me many clues to move forward, but there are still plenty of things I can investigate, including domain-naming patterns, sender organization types, infrastructure countries, Microsoft tenant and mail-routing clues, message timing and cadence, subject and lure construction, and URL structure. These things might help me understand how the system is automated even though the link infrastructure appears to be gone.

The next thing I am going to do is take a closer look at the sender domains and the Microsoft-related mail information in the headers. I will investigate what public information is available about the sender domains, including whether they appear connected to personal or business services and what infrastructure countries appear in the records. A country connected to a domain, server, or data center does not necessarily reveal where the person sending the email is physically located, so I will treat that information as an infrastructure clue rather than proof of the sender’s location.

I will also look at the timing of the emails to see if there is a pattern that might be helpful.

See you next time.

This article continues Phishing Investigations, Part 2, where I sorted the suspicious messages and developed a working theory about the campaign.

To begin the technical analysis of the emails I have labeled the “John Doe” messages, I created a table in my private database. A spreadsheet would work just as well, but I wanted one place where I could compare the same details across every message.

I am keeping the actual addresses, domains, message identifiers, and links private. Publishing those values could expose personal information or encourage someone to open a potentially dangerous URL. The purpose of this article is to document my investigation and reasoning, not to publish the raw evidence.

Building the comparison table

For each email, I recorded the following fields:

• Date received
• Sender email address
• Sender domain
• Microsoft tenant ID and tenant domain
• Subject line
• Exact lure text
• URL
• Subdomain
• Root domain
• Message ID

Once I entered the messages, I compared the rows to see whether any values repeated.

What I found

The first result was a little disappointing because most of the obvious indicators were unique:

• Each message used a different sender email address.
• Each sender domain was different.
• Each Microsoft tenant ID and tenant domain was different.
• Each subject line was different, although every subject promised pictures.
• The wording changed, but every lure used pictures from the past to create curiosity or nostalgia.
• Each message contained a different URL and subdomain.

The Microsoft authentication-source values were also unique. However, they all ended in prod.outlook.com, and two shared the longer ending LAMP152.PROD.OUTLOOK.COM.

At first glance, I thought the Outlook suffix might mean that each message came from a compromised Microsoft 365 account. After checking that assumption, I realized the evidence does not support that conclusion yet. The suffix shows that Microsoft-hosted mail infrastructure was involved, but it does not tell me whether the sender used a compromised account, an attacker-created account, an abused service, forwarding, or some other type of relay.

That correction matters. A good investigation has to separate what the evidence shows from what the investigator suspects. Before I can make a stronger claim about the accounts, I need to compare the full message headers, including the SPF, DKIM, DMARC, and composite authentication results described in Microsoft’s message-header documentation.

The campaign fingerprint so far

Although I did not find a simple repeated address or domain, I can still see the outline of a campaign fingerprint:

• The sender identities and technical indicators change from message to message.
• The lure consistently promises old pictures or memories.
• Microsoft-hosted mail infrastructure appears in the routing information.
• The links look disposable because every message uses a different URL and subdomain.
• The campaign has continued over time, with another message arriving roughly every three to four days.

This does not identify the person or group responsible. It also does not prove that every message came from the same system. It is simply my current working theory based on the behavior I can observe.

My next step

The sender information did not give me enough to solve the mystery, so my next step is to investigate the link infrastructure. For each link, I plan to add these fields to my private database:

• Root domain
• Domain creation date
• Registrar
• Nameservers
• First-seen date
• Current IP address
• Historical IP addresses
• Autonomous system number (ASN)
• TLS certificate details
• Redirects
• Final destination and final root domain
• URL path
• URL query parameters

I will collect this information through passive research whenever possible. I will not open the suspicious links directly in my everyday browser. I will also remove personal information before submitting any indicator to a third-party analysis service, because some services retain or share submitted data.

What I hope to learn

The individual domains may be unique at the surface but still converge deeper in the infrastructure. For example, several unrelated-looking domains might use the same nameservers, hosting provider, tracking service, certificate, IP history, or final destination. A repeated connection like that would be a stronger clue than the shared lure alone.

It is also possible that the research will not reveal a connection. That would not make the investigation a failure. It would mean the current evidence is not strong enough to confirm my theory, and I would need to document that result instead of forcing an answer.

This part of the investigation is still open. It will take time to research the domains and compare the results safely. In the next part, I will share what I find, explain which connections appear meaningful, and decide what to investigate next.

Until next time!

This article continues Phishing Investigations, Part 1, where I described how I began collecting suspicious messages for safe analysis.

Sorting the Spam Messages

After reviewing approximately 120 spam emails by hand, I was surprised—and somewhat relieved—to find that only about 17 appeared questionable enough to justify a deeper investigation. Most of the remaining messages were advertisements, unwanted marketing, or other low-value mail.

This does not mean the 17 messages have already been proven malicious. At this stage, they are simply suspicious messages that need to be classified and investigated carefully.

Most of them fit into one of two patterns:

1. A sender claiming to be someone who worked with me many years ago when I was a line cook. The sender knew the correct restaurant and claimed to have old photographs that I needed to see.
2. Messages claiming to come from Gmail and warning that I would lose my account and access to my email unless I followed a set of instructions.

Both campaigns looked convincing enough to deserve further review, so I separated them into two groups for investigation.

The “John Doe” Campaign

I began with the former-coworker messages because they appeared to be aimed at me personally and included information about someone I really knew. I will use the name “John Doe” throughout this project to protect the person’s identity. Nothing at this stage proves that the real person had any involvement in the messages.

How Did the Campaign Connect Me to an Old Coworker?

I started by searching my email history to see whether I had ever exchanged messages with the real John Doe. If I had, a compromised mailbox or address book could have been one possible explanation. I also hoped to find a trusted email address so I could warn him and ask whether he had received similar messages.

However, I found no past email conversation with him and did not have a verified way to contact him.

I am still in regular contact with another former employee from the same restaurant, so I asked whether she had received similar messages. She said she had not received messages using John Doe’s identity, but she had received repeated messages claiming to come from another former coworker, whom I will call “Jane Doe.”

She correctly chose not to open attachments, download files, or interact with the messages. Because I could not examine the original messages or their headers, I can treat her report only as supporting information—not confirmed technical evidence.

It was interesting that the messages sent to me used the identity of a man while the messages sent to her used the identity of a woman. However, that detail alone does not prove the campaigns came from the same source.

Developing a Working Hypothesis

The reports suggest that someone may be using information that connects several former restaurant employees. One possible source is old social-media content, such as public Facebook posts, tags, friend connections, or data collected through scraping.

That is only a hypothesis. Other possibilities include a compromised address book, a breached account belonging to someone in the group, an old contact database, or information gathered from multiple public sources.

A good investigation should separate observations from assumptions. At this point, I know that the messages reference real relationships and that another former employee reported a similar pattern. I do not yet know who sent the messages, how the relationships were discovered, or whether the two campaigns share the same operator.

What Comes Next

The next step is to examine the saved messages themselves. I will review their headers, sender domains, Reply-To addresses, authentication results, links, and other indicators that may help identify how the campaign works.

Any personal information will remain private, and conclusions will be based on evidence rather than speculation.

See you in Part 3.

After completing the SOC Level 1 learning path on TryHackMe, I wanted to move beyond simulations and practice defensive work using real data. Artificial intelligence can assist with repetitive tasks such as reviewing large quantities of logs, but analysts still provide context, verification, documentation, and judgment. I want to strengthen that human side of the process.

I began by hardening and monitoring my home network. I also reviewed my Windows and antivirus logs and established a routine for checking them. I was glad to find no obvious signs of a current problem, but that left me looking for another safe, practical project that could help sharpen my SOC skills.

Finding a Real-World Dataset

Next, I turned to the spam folder in my Gmail account. That is where I began finding messages worth investigating. Gmail had already filtered them away from my inbox, but simply ignoring or deleting suspicious messages would not teach me how to examine them.

At the time of this writing, the folder contained more than 120 messages. That does not mean every message was malicious. A spam folder can contain unwanted advertising, low-quality marketing, scams, phishing attempts, and even legitimate mail that was classified incorrectly. However, it gave me a useful set of messages to triage and classify.

The First Collection Problem

My first challenge was collecting the messages in a format suitable for investigation. Google supports exporting Gmail data through Google Takeout, including message content, headers, attachments, and Gmail labels such as Spam. However, I ran into a problem while trying to complete the export using the options available in my account.

Rather than conclude that bulk export was impossible, I treated this as a workflow problem that still needed troubleshooting. For my first pass, I decided to download selected messages individually as .eml files. Gmail allows individual messages to be downloaded in this format, which preserves information that can be useful during an investigation.

There is also a time limit to consider: Gmail automatically deletes messages that remain in Spam for more than 30 days. That means I need a repeatable collection process instead of relying on the spam folder as permanent storage.

Handling Suspicious Email Safely

Every message in this project will be treated as untrusted. My basic precautions include:

• Keeping automatic loading of remote images disabled.
• Not clicking links inside suspicious messages.
• Not replying to the sender.
• Not opening or running attachments.
• Saving investigation files separately from important personal files.
• Recording only the information needed for analysis.
• Removing personal details before publishing examples or results.

These precautions reduce risk, but they do not eliminate it. Anyone examining suspicious email should use an isolated analysis environment and appropriate security tools rather than casually opening files on a primary computer.

What Comes Next

The next step is to create a consistent process for collecting and documenting the messages. I will need to decide which details to record, such as the visible sender name, actual sender address, Reply-To address, authentication results, links, attachment types, dates, and the reason each message appears suspicious.

I will also need a safe system for collecting new samples before Gmail removes them. Once the messages are organized, I can begin looking for patterns and documenting the investigation process without exposing private information.

I will continue the series when the first set of messages is safely collected and ready for analysis.

---

Strengthen the network behind your investigation: Before analyzing suspicious email, make sure the network and devices you use have a solid security foundation. Read The Complete Home Router Security Guide: Audit, Protect, Monitor, and Improve Your Network.

Phishing emails are designed to appear as though they came from a person or organization you trust. Attackers may copy a company’s logo, colors, writing style, and email layout. However, one important detail can expose the deception: the sender’s actual email address.

Checking that address should be one of the first things you do before clicking a link, opening an attachment, replying, or providing information.

The Display Name Can Be Misleading

Most email programs prominently display a sender’s name, such as:

• Your Bank
• Microsoft Support
• Amazon Billing
• Company Payroll

Unfortunately, the sender can usually choose almost any display name. An attacker could enter “Your Bank” even though the message was sent from an unrelated address.

The name alone does not prove who sent the email. You must reveal and inspect the complete email address behind it.

How to Reveal the Full Address

The exact steps vary between email programs, but you can normally reveal the complete address by:

• Clicking or tapping the sender’s name.
• Selecting a small arrow beside the sender.
• Opening the message details.
• Hovering your mouse pointer over the sender’s name on a computer.

Do not click any links inside the message while checking the sender.

After revealing the address, read it carefully from beginning to end. On a phone, the screen may shorten a long address, so open the sender details if the entire address is not visible.

Understand the Parts of an Email Address

An email address contains a username, the @ symbol, and a domain:

support@example.com

In this example:

• support is the username.
• example.com is the domain.

The domain is especially important because it identifies the email system that sent or authorized the message.

An attacker might create an address such as:

amazon-support@example.com

The word “amazon” appears in the username, but the actual domain is still example.com. The address does not belong to Amazon.

Always focus on what appears after the @ symbol.

Watch for Lookalike Domains

Phishing addresses often use domains that resemble legitimate ones. Attackers may:

• Add an extra letter.
• Remove a letter.
• Replace a letter with a similar-looking character.
• Insert words such as “secure,” “billing,” or “support.”
• Add extra words before the real ending of the domain.
• Use an unfamiliar domain ending.

For example, an attacker could register a domain that looks similar to a well-known company’s domain when read quickly.

Be especially careful with addresses containing long strings of words. In an address such as:

security@company.example.com.attacker.example

the real controlling domain is at the end—not the familiar company name near the beginning.

Compare It with a Trusted Source

If you are uncertain, do not use contact information provided in the suspicious email.

Instead, compare the sender’s domain with one obtained independently from:

• The organization’s official website.
• A previous message you know is genuine.
• A saved contact created from a trusted source.
• A bank card, statement, invoice, or other official document.
• A company directory.
• A phone number you already know is legitimate.

Type the organization’s web address yourself or use a trusted bookmark. Do not reach the official website by following a link in the questionable message.

If the email appears to come from a coworker, friend, or family member, contact that person through a different method. A phone call or a new message sent to a known address is safer than replying directly.

Check the Reply-To Address

Some messages use one address in the From field but direct replies to a different Reply-To address.

A different Reply-To address is not automatically malicious. Businesses sometimes use separate systems to send and receive email. However, an unexpected or unrelated Reply-To domain is a reason to investigate further.

Your email program may reveal the Reply-To address in the message details or full header information.

Advanced Check: Review Authentication Results

Email headers may contain authentication results for technologies called SPF, DKIM, and DMARC. These systems help receiving mail services determine whether a server was authorized to send mail for a domain and whether parts of the message were altered.

Depending on your email provider, these results may appear under options such as:

• View message details
• Show original
• View source
• View headers
• View security details

Results showing a failure can be a strong warning. However, a passing result does not guarantee that the message is safe. A criminal can send authenticated email from a domain they own, and a legitimate account could also be compromised.

Email authentication is useful evidence, but it should not replace careful judgment.

A Matching Address Is Not Proof of Safety

A familiar address lowers suspicion, but it does not prove that a message is legitimate. Attackers may compromise real email accounts or manipulate visible sender information.

Continue to be cautious if a message:

• Creates extreme urgency or fear.
• Requests a password or verification code.
• Asks for payment, gift cards, or financial information.
• Includes an unexpected attachment.
• Directs you to sign in through a link.
• Changes familiar payment instructions.
• Makes an unusual request that does not sound like the sender.

When an important request is unexpected, verify it through a separate, trusted communication channel.

A Quick Sender-Address Checklist

Before trusting an email, ask:

1. Did I reveal the complete sender address?
2. Does the domain after the @ symbol belong to the claimed sender?
3. Are any letters missing, added, or replaced?
4. Is the address unusually long or confusing?
5. Does the Reply-To address point somewhere different?
6. Can I confirm the address through an independent source?
7. Does the message contain any other warning signs?

Checking an email address only takes a few seconds, but it can prevent stolen passwords, malware infections, fraudulent payments, and identity theft. Make it a habit to inspect the sender before acting—especially when an email requests money, credentials, sensitive information, or immediate action.

A home router is more than the device that provides Wi-Fi. It is the main connection point between the internet and the computers, phones, televisions, game systems, cameras, appliances, and smart devices inside a home.

Because so much traffic passes through it, the router is an important part of a home-security strategy. A poorly protected router can expose devices, redirect traffic, reveal browsing activity, or provide an attacker with a way into the network.

Router security is not accomplished by changing one setting. It involves understanding the equipment, securing administrative access, identifying connected devices, reducing unnecessary exposure, monitoring activity, and documenting changes.

This guide provides a practical roadmap. Each section also links to a more detailed article for readers who want step-by-step instructions.

1. Begin With a Router Security Audit

The first step is to establish what the router is, how it is configured, and whether it needs immediate attention.

A basic audit should include:

• Router manufacturer and model
• Firmware version
• Date of the latest available update
• Administrative-access method
• Internet and Wi-Fi settings
• Connected devices
• Remote-access features
• Port-forwarding rules
• DNS configuration
• VPN services
• File-sharing services
• Logging and monitoring options

Record sensitive information privately. Public articles and screenshots should not reveal public IP addresses, Wi-Fi passwords, administrator usernames, MAC addresses, serial numbers, device names, or detailed network diagrams.

For a complete starting process, read How to Perform a Home Router Security Audit.

A router audit should be repeated after a firmware update, configuration change, suspected attack, unexplained outage, or the addition of major new devices. A shorter review every three or four months can help identify gradual changes.

2. Secure the Administrator Account

Anyone who gains access to the router’s administrator account may be able to change DNS servers, create port-forwarding rules, monitor connected devices, modify firewall settings, or disconnect users.

The administrator password should be long, unique, and different from every other password. A password manager can generate and store it securely.

Passwords do not need to be replaced according to an arbitrary schedule. Change the router password immediately if:

• It was reused on another account.
• It may have been exposed in a breach.
• It was entered into a suspicious page.
• Someone who knew it should no longer have access.
• Unexplained configuration changes appear.
• Router logs show suspicious administrative activity.

For current guidance on creating, changing, and storing passwords, read How Often Should You Change Your Passwords? A Practical Security Guide.

Whenever possible, restrict the administrator panel to the trusted local network. Do not expose it directly to the internet simply for convenience.

3. Understand HTTPS and SSH

Router administration pages may offer an option such as Force HTTPS. HTTPS encrypts information exchanged between the browser and the router, helping protect administrator credentials and configuration data from interception on the local network.

A locally issued router certificate may still produce a browser warning. That warning does not necessarily mean encryption is absent, but it should not be ignored without confirming that the browser is connected to the correct router.

Learn more in What Does the Force HTTPS Router Setting Do?

SSH is another administrative service. It provides powerful command-line access and may be useful for troubleshooting, automation, installing packages, or making advanced configuration changes.

That power also increases risk. Readers who do not use SSH should consider disabling it. If it is required, restrict it to the trusted local network, use strong authentication, and never expose it to the internet without a carefully designed security plan.

Read What Is SSH on a Router, and Should You Disable It? before changing this setting.

4. Create a Private Device Inventory

It is difficult to protect a network without knowing what is connected to it.

A device inventory should identify every computer, phone, television, console, printer, camera, appliance, and smart device. Useful private records include:

• Device name
• Owner
• Device type
• IP address
• MAC address
• Connection method
• Network or Wi-Fi band
• Purpose
• Date identified
• Whether the device is trusted
• Whether it receives security updates

Some phones and computers use private or randomized MAC addresses. This is a privacy feature and does not automatically indicate an intruder. Confirm devices by temporarily disconnecting them, checking their network settings, or watching which router entry disappears.

Unknown devices should be investigated before being permanently blocked. A television, streaming device, appliance, or phone using a private MAC address may initially appear without a recognizable name.

Follow the full process in How to Create a Private Inventory of Devices on Your Home Network.

5. Separate Smart Devices From Important Computers

Smart devices frequently receive fewer updates than computers and phones. Some use outdated software, weak security controls, or cloud services that may eventually be abandoned.

Placing smart devices on a guest or IoT network can reduce the harm caused if one becomes compromised. This practice is called network segmentation.

A segmented network may contain:

• A trusted network for computers, phones, and sensitive work
• An IoT network for televisions, speakers, appliances, and cameras
• A guest network for visitors
• An isolated test network for unfamiliar equipment

Device isolation can prevent clients on the same network from communicating directly. However, isolation may interfere with printing, casting, media sharing, or device-control applications. Test important functions after enabling it.

Read Why Smart Devices Should Be Separated from Your Main Network for a fuller explanation.

6. Check for Internet Exposure

A router should normally block unexpected connections arriving from the internet. Certain settings can change that behavior.

Review:

• Remote administration
• Port forwarding
• DMZ settings
• Universal Plug and Play
• VPN servers
• File-sharing services
• SSH access
• Cloud-management features

A port that appears open is not automatically evidence of an attack, but it should correspond to a service the network owner understands and intentionally enabled.

Online port-checking services should be used carefully. Never download an unknown “scanner,” expose a service merely to test it, or publish a complete list of open ports associated with a real network.

Use How to Check Whether Your Router Is Exposed to the Internet as the detailed checklist.

7. Add Network-Wide DNS Filtering

DNS filtering can prevent devices from resolving certain advertising, tracking, phishing, malware, or other unwanted domains.

A platform such as AdGuard Home can provide filtering for devices that cannot run browser extensions, including televisions, consoles, speakers, and smart appliances.

DNS filtering can help with:

• Known malicious domains
• Some phishing destinations
• Advertising and tracking domains
• Unwanted telemetry
• Visibility into domain requests

It cannot:

• Remove malware already installed on a device
• Examine all encrypted traffic
• Block every newly created malicious domain
• Stop connections made directly to IP addresses
• Protect devices that bypass the filtered DNS server
• Replace antivirus software, updates, firewalls, or safe browsing

DNS query logs can reveal household activity. Store them privately and remove identifying information from published results.

Read What Network-Wide DNS Filtering Can—and Cannot—Protect You From.

8. Monitor Logs and Investigate Carefully

Router logs may contain information about:

• Administrative login attempts
• Devices connecting and disconnecting
• Firewall activity
• Internet-connection failures
• DHCP assignments
• Software errors
• Service starts and stops
• Router restarts

One unusual line is not proof of an attack. Compare events with normal activity, scheduled maintenance, power failures, firmware updates, and known devices.

Preserve suspicious logs before rebooting because some routers store them only temporarily. When documenting an incident publicly, remove IP addresses, MAC addresses, usernames, hostnames, and other identifying information.

For a practical review process, read How to Review Router Logs for Suspicious Activity.

9. Use Packet Capture for Deeper Analysis

When logs do not provide enough detail, packet capture can show how devices communicate.

Packet analysis can help investigate:

• Failed connections
• DNS problems
• Unexpected destinations
• Repeated connection attempts
• Unusual protocols
• Devices communicating when they should be idle
• Performance problems

Packet captures may contain sensitive information, including local addresses, domain requests, session information, and unencrypted content. Only capture traffic on networks and devices you own or are authorized to examine.

Use narrow filters, short capture times, and a clear question. A small targeted capture is easier and safer to analyze than an unrestricted capture of the entire network.

Read How to Capture and Read Network Packets Safely Using a Router.

10. Establish a Performance Baseline

Security investigations are easier when normal performance is already documented. Slow internet does not always mean malware or an attack. Congestion, Wi-Fi interference, faulty cables, overloaded devices, provider problems, and background updates can all affect speed.

Test:

• Download speed
• Upload speed
• Latency
• Jitter
• Packet loss
• Ethernet performance
• Wi-Fi performance at several distances
• Performance at different times of day

Record the test method and general conditions without publishing an exact address, public IP address, account number, or identifiable device information.

Start with Why You Should Test Your Internet Connection—and How to Do It Safely.

Newer routers and devices may also support Wi-Fi 7 Multi-Link Operation, or MLO. MLO can allow compatible devices to use more than one wireless link, but the result depends on client support, distance, interference, router configuration, and internet speed.

See Does Wi-Fi 7 MLO Improve Real Home-Network Performance? for a structured comparison of Ethernet, 2.4 GHz, 5 GHz, 6 GHz, and MLO.

11. Use Advanced Router Features Safely

Many routers include useful features that require additional security decisions.

Router VPNs

A router may include VPN client and server capabilities, but the software built into the router is not necessarily a subscription to a commercial VPN provider.

A VPN client can route selected devices through a VPN service. A VPN server can provide authorized remote access back to the home network. These are different functions and have different risks.

Streaming services may restrict VPN use, block certain servers, or apply regional licensing rules. Review the service’s terms before attempting to change a streaming location.

Read Router VPNs Explained: What Is Built In, What Costs Money, and Can They Change Your Streaming Location?

USB Network Storage

A compatible router can turn a USB drive into basic network storage. This can be convenient for transferring files or sharing documents inside a household.

Use named accounts and strong passwords, disable guest access when unnecessary, and keep WAN access turned off. Router-based storage should not be the only copy of an important file.

Read How to Turn a USB Drive into Private Network Storage Using a Router.

Router Plugins

OpenWrt and OpenWrt-based routers may support packages for monitoring, DNS filtering, traffic management, Dynamic DNS, storage, Wake-on-LAN, and other functions.

Every installed service increases complexity and may create new maintenance or security requirements. Before installing a package:

• Back up the router configuration.
• Confirm firmware and processor compatibility.
• Check available memory and storage.
• Use the official package repository.
• Install one package at a time.
• Document the change.
• Test the router afterward.
• Remove unused packages.

Explore the options in 10 Useful OpenWrt Router Plugins—and What They Actually Do.

A Practical Router-Security Schedule

Every Month

• Check for firmware updates.
• Review important security alerts.
• Confirm that the router is operating normally.
• Investigate unexpected outages or restarts.

Every Three or Four Months

• Review connected devices.
• Update the private inventory.
• Check password-manager warnings.
• Review remote-access and port-forwarding settings.
• Examine router logs.
• Test internet performance.
• Confirm that backups are usable.

Once a Year

• Perform a complete router audit.
• Review every enabled service.
• Remove obsolete devices and rules.
• Test guest and IoT isolation.
• Review DNS-filtering rules.
• Confirm that recovery information is available.
• Decide whether the router still receives security updates.

Immediately After Suspicious Activity

• Preserve logs and relevant evidence.
• Disconnect or isolate suspicious devices.
• Change compromised passwords from a known-clean device.
• Review DNS, firewall, forwarding, and administrator settings.
• Update vulnerable systems.
• Check for unfamiliar accounts or configuration changes.
• Restore a trusted configuration if necessary.
• Continue monitoring after the immediate problem is resolved.

Final Thoughts

Home-router security is a continuous process rather than a one-time configuration project.

Begin by auditing the router and identifying every connected device. Secure administrative access, reduce internet exposure, separate less-trusted equipment, and add monitoring where it provides useful information. Establish a performance baseline so ordinary technical problems are easier to distinguish from suspicious behavior.

Advanced features such as VPNs, USB storage, packet capture, DNS filtering, and plugins can make a router considerably more useful. They should be enabled only when their purpose is understood and their access can be controlled.

The most effective network is not necessarily the one with the greatest number of features. It is the one whose devices, services, risks, and changes are understood and documented.

Passwords protect email, financial accounts, social media, shopping accounts, cloud storage, and many other services. Unfortunately, outdated password advice can make account security more difficult than it needs to be.

Many people were once told to change every password every 30, 60, or 90 days. Current guidance takes a different approach: create strong, unique passwords and change them when there is a reason—not simply because the calendar says so.

How Often Should a Password Be Changed?

A strong, unique password does not normally need to be changed on a fixed schedule.

The current NIST Digital Identity Guidelines advise organizations not to require arbitrary periodic password changes unless there is evidence that a password has been compromised or the user requests a change.

Frequent forced changes can encourage people to create predictable passwords such as:

• Summer2026!
• Summer2026!!
• Fall2026!
• PasswordJuly1!

An attacker who discovers one version may be able to guess the next one.

Instead of automatically replacing passwords every few months, conduct a password-security review several times a year. Look for reused, weak, old, or exposed credentials, but only change the passwords that need attention.

Change a Password Immediately When:

• A company reports a data breach involving passwords.
• A password manager or browser reports that the password was exposed.
• An unfamiliar device or location appears in the account’s login history.
• Someone successfully—or unsuccessfully—attempts to access the account.
• The password was entered into a suspicious website or phishing page.
• A computer or phone may contain malware or a keylogger.
• The password was accidentally shared, emailed, posted, or displayed publicly.
• The same password was used on another account that was compromised.
• Someone who knew a shared password should no longer have access.

If a reused password is exposed, replace it on every account where it was used. Begin with email, financial accounts, cloud storage, and the password manager itself.

The Federal Trade Commission also recommends changing a password immediately when a company reports that it was stolen in a breach.

What Makes a Password Strong?

The most important qualities are length, randomness, and uniqueness.

Every account should have a different password. Reusing one strong password across several websites is dangerous because attackers can take credentials stolen from one website and try them elsewhere. This is called credential stuffing.

When a password must be memorized, aim for at least 15 characters. Longer is generally better. A passphrase made from several unrelated words can be easier to remember than a shorter collection of symbols.

For example, the structure could resemble:

Lantern-River-Coffee-Planet-Window

Do not use that example as an actual password. Any password published online should be considered unsafe.

Avoid:

• Names of family members or pets
• Birthdays, addresses, and phone numbers
• Keyboard patterns such as qwerty
• Number sequences such as 123456
• Famous quotations and song lyrics
• Common words followed by a year or exclamation point
• Slight variations of passwords used on other accounts

NIST recommends using a password manager and making memorized passwords at least 15 characters long.

Let a Password Generator Do the Work

People are not very good at creating truly random passwords. A password generator can create a long, unpredictable password such as a random combination of letters, numbers, and symbols.

For passwords stored in a manager, consider generating at least 16 to 20 characters—or the longest password the website accepts. Because the manager remembers it, the password does not need to be easy to type or memorize.

Never paste a real password into an unfamiliar online “password strength checker.” A malicious or poorly protected checker could collect it.

Tools for Creating and Storing Passwords

A password manager is an encrypted vault that generates, stores, and fills passwords. It allows every account to have a unique password without requiring the user to memorize them all.

Common options include:

• Apple Passwords for people who primarily use Apple devices
• Google Password Manager for Chrome, Android, and Google accounts
• Microsoft Edge Password Manager
• Firefox Password Manager
• Dedicated password managers such as Bitwarden

These are examples, not endorsements. Compare reputable reviews, supported devices, security features, update history, recovery options, and cost before choosing a manager.

A browser’s built-in manager may be the easiest starting point. A dedicated manager may be preferable when passwords must work across several browsers, operating systems, or family members.

Protect the Password Manager

A password manager concentrates many credentials in one place, so the vault itself needs strong protection.

• Create a long, unique master passphrase.
• Never reuse the master passphrase anywhere else.
• Enable multifactor authentication on the vault.
• Keep the manager and all connected devices updated.
• Configure the vault to lock automatically.
• Store recovery information in a secure offline location.
• Learn the recovery process before an emergency occurs.
• Never approve an unexpected login notification.

Do not store the vault’s master password inside the vault as the only copy. If it must be written down, keep it in a locked and private physical location—not on a note attached to the computer.

For family or business passwords, use the manager’s secure sharing feature instead of sending credentials by text message or email.

Turn On Multifactor Authentication

Even an excellent password can be stolen through phishing, malware, or a data breach. Multifactor authentication, also called MFA or two-factor authentication, requires another form of verification.

An authenticator app, hardware security key, or passkey is generally preferable to a code delivered by email or text when stronger options are available.

According to CISA, strong passwords, a password manager, and MFA are among the most important steps people can take to protect their accounts.

Email deserves special attention because password-reset messages for other accounts are often delivered there. Protect the primary email account with a unique password and MFA.

Consider Using Passkeys

Some services now support passkeys. A passkey uses cryptographic credentials stored on a trusted device instead of a traditional password. Passkeys can be easier to use and are more resistant to phishing.

When a reputable service offers a passkey, consider enabling it. Keep recovery information current and protect every device that can access the passkey.

A Simple Password-Security Routine

Once every three or four months:

1. Open the password manager’s security or password-health report.
2. Look for reused, weak, and exposed passwords.
3. Replace the most important risky passwords first.
4. Review recent activity on email and financial accounts.
5. Remove old accounts and unfamiliar signed-in devices.
6. Confirm that MFA and recovery information still work.
7. Install updates for the password manager, browser, and operating system.
8. Check that recovery codes remain available in a secure location.

This is a security review—not a requirement to replace every healthy password.

Final Thoughts

Passwords should be changed because something has increased the risk, not merely because a certain number of days have passed.

The strongest practical approach is to use a password manager, generate a different long password for every account, protect the vault with MFA, and respond immediately to breach warnings or suspicious activity.

A person who uses 100 unique generated passwords is generally safer than someone who regularly rotates one memorable password across 100 accounts.

Routers that use OpenWrt or an OpenWrt-based operating system can often be expanded with installable packages. These packages are sometimes called plugins, applications, or add-ons.

A package beginning with luci-app- normally adds a graphical management page to LuCI, OpenWrt’s web interface. It may also install the underlying service automatically. Package availability varies by router, processor, firmware version, and available storage, so readers should confirm compatibility before installing anything.

Here are ten useful router plugins covering security, troubleshooting, performance, monitoring, and convenience.

1. tcpdump: Capture and Examine Network Packets

tcpdump is a command-line packet-capture tool. It can show live packet summaries or save selected traffic in a PCAP file for examination in Wireshark.

It is useful for investigating failed connections, DNS problems, unexpected communication, and unusual traffic patterns. Captures can be limited by device, protocol, interface, port, packet count, or time.

Packet captures may contain addresses, domain requests, session information, and unencrypted data. Capture files should therefore be stored privately and never uploaded to an unknown analysis service.

Official OpenWrt tcpdump information

2. luci-app-sqm: Reduce Bufferbloat and Latency

Smart Queue Management, commonly installed through luci-app-sqm and sqm-scripts, manages how traffic waits to leave the network.

Without effective queue management, a large download or upload can cause substantial delays for gaming, video calls, remote work, and ordinary browsing. This problem is known as bufferbloat.

SQM normally works by shaping the connection slightly below its maximum speed. The measured top speed may decrease, but the connection can feel more responsive while busy. Accurate upload and download values are essential; incorrect settings can unnecessarily limit performance.

OpenWrt SQM documentation

3. luci-app-nlbwmon: Track Bandwidth by Device

luci-app-nlbwmon adds a graphical interface for OpenWrt’s network bandwidth monitor. It helps show how much traffic individual network devices have uploaded and downloaded.

This is useful for identifying heavy bandwidth users, investigating unexpected increases in data usage, and establishing a baseline for normal device behavior.

Bandwidth monitoring does not automatically prove that a device is malicious. Software updates, cloud backups, streaming, and game downloads can all generate large amounts of legitimate traffic.

Official nlbwmon package information

4. luci-app-statistics: Create Historical Router Graphs

luci-app-statistics uses tools such as collectd and RRDTool to create graphs showing network utilization, processor load, memory usage, ping results, uptime, disk activity, temperatures, and other measurements.

Historical information is valuable because it allows an administrator to compare current behavior with earlier conditions. It can help identify recurring outages, overloaded interfaces, increasing memory use, or performance changes.

Statistics are commonly stored in temporary memory by default and may disappear after a reboot. Persistent storage must be configured carefully because repeatedly writing data to the router’s internal flash can shorten its life. An external USB drive or another monitoring system may be a better destination.

OpenWrt statistics documentation

5. luci-app-adblock: Add Network-Wide DNS Filtering

luci-app-adblock uses DNS blocklists to prevent devices from resolving known advertising, tracking, or abusive domains. One router-level installation can provide filtering for many devices without requiring a browser extension on each one.

DNS filtering can reduce unwanted connections, but it is not an antivirus product. It cannot examine encrypted webpage contents, repair an infected computer, or guarantee that every malicious destination will be blocked. Devices using their own encrypted DNS service may also bypass the router’s filtering.

Do not run multiple DNS-filtering platforms simultaneously unless their interaction has been planned. For example, a router that already uses AdGuard Home may not need another DNS-blocking package.

OpenWrt ad-blocking options

6. luci-app-banip: Block Known Unwanted IP Ranges

banIP, managed graphically through luci-app-banip, can load IP-address blocklists into the router’s firewall. Lists may identify addresses associated with abuse, unwanted geographic regions, suspicious networks, or other categories.

This can reduce unwanted connection attempts, but it does not replace a properly configured firewall, secure passwords, firmware updates, or device protection. Large blocklists may consume memory and processing resources. They can also cause false positives by blocking legitimate services that share cloud or hosting infrastructure.

Start with a small, clearly understood list and review the logs before adding more.

OpenWrt banIP documentation

7. luci-app-watchcat: Recover from Connection Failures

Watchcat monitors connectivity by periodically contacting a chosen destination. If the test repeatedly fails, it can restart a network interface or reboot the router.

This can be helpful in locations where an unreliable modem or internet connection occasionally stops responding. It can restore service without requiring someone to unplug the equipment.

Watchcat must be configured conservatively. A blocked ping, temporary outage, or poorly selected test destination could cause unnecessary restarts. Automatic recovery should not conceal a recurring problem that requires proper investigation.

Official Watchcat package information

8. luci-app-ddns: Keep a Hostname Updated

Many home internet connections receive a public IP address that can change. Dynamic DNS automatically updates a hostname whenever that address changes.

The luci-app-ddns package provides a graphical interface for supported Dynamic DNS services. This can be helpful when using an authorized VPN server or another securely configured remote-access service.

Dynamic DNS does not secure the router, open a port, or provide a VPN by itself. It only associates a name with the current address. Exposing an administrative page directly to the internet remains dangerous even when Dynamic DNS is used.

OpenWrt Dynamic DNS documentation

9. luci-app-wol: Turn On Compatible Computers Remotely

Wake-on-LAN allows a router to send a special “magic packet” that wakes a compatible computer. luci-app-wol provides a graphical interface for this function.

It can be useful for a computer that does not need to run continuously but occasionally must be accessed for backups, file storage, or authorized remote work.

The computer’s motherboard, network adapter, operating system, and power settings must support Wake-on-LAN. It is usually most reliable over Ethernet. Wake-on-LAN turns the computer on; it does not authenticate a user or provide secure remote access.

OpenWrt Wake-on-LAN documentation

10. luci-app-ksmbd: Share USB Storage on the Local Network

luci-app-ksmbd provides a web interface for configuring KSMBD, a lightweight SMB file server. It can turn a USB drive connected to a compatible router into basic local network storage.

Readers can use it to share documents, transfer files, or create a temporary household storage location. KSMBD generally requires fewer router resources than a complete Samba installation, although it also has fewer features.

File sharing should be restricted to the trusted local network. Use named accounts and strong passwords, disable guest access when it is unnecessary, and never expose SMB directly to the internet. Router storage should not be treated as the only copy of an important file.

OpenWrt KSMBD documentation

Installing Router Plugins Safely

Before installing any package:

1. Create a router configuration backup.
2. Confirm that the package supports the router’s firmware and processor.
3. Check available flash storage and memory.
4. Use the router’s official package repository.
5. Refresh the package list without blindly upgrading every installed component.
6. Install one package at a time.
7. Record what was installed and why.
8. Test the router after each change.
9. Remove packages that are no longer used.
10. Keep administrative services inaccessible from the internet.

Vendor firmware may already provide equivalent functionality. Installing a second firewall, DNS service, file server, VPN manager, or monitoring system can create conflicts. Built-in tools should be reviewed before adding replacements.

Final Thoughts

Router plugins can transform a basic gateway into a monitoring, troubleshooting, filtering, storage, and performance-management platform. However, every additional service increases complexity and may introduce new security or maintenance requirements.

The best plugin is not necessarily the one with the most features. It is the one that solves a defined problem, fits within the router’s resources, comes from a trusted source, and can be configured and maintained safely.

Begin with one low-risk tool, document the original configuration, test the results, and only then consider adding another package.