DEV Community: Dallas Baker

Reconnaissance

Dallas Baker — Wed, 25 Mar 2026 02:13:07 +0000

Most of all attacks on your network will begin with them trying to gain as much information about you as possible. With the amount of data readily accessible on the web and even the dark web, it's almost child's play to get information. Sometimes the most straightforward and the most effective way to get information is to fake an interview. I had a recent interview where the lead DevOps engineer gave away his entire infrastructure and all the security holes they hoped to fill. I will not talk about how to do this, but you as a company or security professionals should be aware not everyone is not honestly interviewing for the position. Some banking customers rob their bank, so whos to say that a potential employee doesn't have other means besides actually providing their expertise. See my post on social engineering to better understand how to protect your company from this type of threat. Aside from using social engineering attackers have an arsenal of tools that allow them to probe and scan your network to extract data about your systems. Let's review them and how to prevent these tools from harming your network.

Whois

When registering your company domain, you provide the registrar information concerning your postal address, phone numbers, a point of contact, and authoritative domain name servers. Most of this information can be used to conduct social engineering and scanning attacks. Whois is easily accessible from the web or on UNIX systems from the terminal. Another useful bit of information whois provides is if your organization was assigned a block of IP addresses. These IP addresses can be used to scan and probe your network for openings. Even if the only thing they get is your DNS, this is very useful for the next phase of the attack.

Defense

Sadly you have very little real defense here, and unfortunately, you're forced to accept this is the way the internet is. You can choose to use fake information to register your domain to prevent social engineering but what and if there is an emergency and someone needs to contact you? Some companies allow you to register through them and enter their contact information instead of yours. The possible negative here is incident handlers often rely on whois to contact each other quickly when there is an incident. Time is not on our side, so this gives the attacker more time for an attack. The only best solution is to use your company's organization name in replace of real names for contact. This abstraction limits the value for social engineers, however, be sure to have someone who can respond to any request via whois. You want to limit social engineering but allow someone to get to an incident handler when it's necessary.

Dig and nslookup

Domain name systems are full of useful information about a target. An attacker will use tools like dig or nslookup to discover as many IP addresses as possible. If an attacker is allowed to complete a zone transfer, they can dump all the records associated with a particular domain.

Windows

Using PowerShell complete the following commands to perform a zone transfer and dump the records.

# executes the nslookup application in windows
nslookup
# changes the default server to the specified DNS domain.
server $DNS_ip_addres_or_name_youre_trying_to_attack
# changes the resource record type for the query.
set type=any
# lists information for a DNS domain. -d is equal to set type=any
ls -d $target_domain
# dump packets using port 53 using TCP dump
# -nn means to not resolve IP addresses and to include port numbers
tcpdump -nn port 53 and host $DNS_IP

NSLOOKUP Command Line | Windows Command Line.

Useful tip: if you have a list of IP addresses you would like to target code a for-loop to iterate over each DNS and execute the following and export your results in a text file.

Unix

Using shell use the following command to initiate a zone transfer

# -t AXFR sets query type to zone transfer
dig @$DNS_Server_IP $domain_name -t AXFR

Perform TCP dump and iterate over a list of IPs if you have multiple targets

Defense

Only allow zone transfers from your secondary DNS
Secondary DNS should not allow zone transfers from anyone
Use split DNS
- External names should be on your external DNS
- Internal names should be on your internal DNS

Web searches and Google Hacking

Corporate websites almost always contain contact information like phone numbers and computing platforms or architecture. This information is useful for social engineering attacks and knowing which exploits to use against your system. Search engines are also helpful for searching for information about a target. Job boards are too precious in gathering information about a company's infrastructure and platforms. An attacker could then try his/ her luck in applying and talking to HR to collect even more information. Google hacking is an entire subject within its self and will not be discussed in this post, however, google dorks is an excellent tool for beginners to get the idea.

Other Tools

PIPL

PIPL is a great tool to find users and their associated accounts. Most people use the same username for all of their accounts so from there you can use NAMECHK to see what other accounts they may have to craft an email spoofed as XM Radio asking to update their account information with a link to malicious code.

NAMECHK

Namechk searches for a particular username and returns all accounts associated with those usernames. The tool was originally designed to allow users to chose a username that will be unique to them.

Pushpin

Pushpin is personally the greatest tool for social engineering. You can track peoples social media post and location. You could craft a text message or email asking how the concert was or pose as a friend they may have made. Another great feature is it returns photos they post to social media. You could clone badges or on the defense side to see if an employee is leaking serial numbers or other secrets.

Defense

Limit and control information
Perform risk analysis on public information
Generalize employment ads
Determine what sites are linking to yours
Look for web spiders and crawlers in web application logs

Web tools

Shodan

Shodan is an online based tool that crawls the internet and indexes service banners. By indexing service banners shodan can keep records of which services are running, open ports, vendor information, and version numbers. In some ways, Shodan is like traditional scanners such as NESSUS. Shodan can allow an attacker to know your network without actually touching it.

Nmap, Network mapping

Nmap is a favorite network-analysis tool used for mapping a network and finding open ports. Nmap maps the network by sending ICMP echo request. If there is a response, Nmap assumes the host is up and if not the host is down. After Nmap confirms the host is up, it begins identifying which ports are open. Because different applications respond to request differently, Nmap can determine the version of the software. For better understanding, I have listed the types of request that can be sent to the responding system.

SYN Synchronize
ACK Acknowledge
FIN Finilize or end connection
RESET End unestablished connection
URG Urgent Data is included
PUSH Data should be pushed through the TCP stack

Nmap allows the attacker to perform various types of scans using these types of request. Below illustrates the types of scans and what makes them unique. I have only listed common and most useful types of scans below. For detailed information please refer to Nmap documentation.

Ping sweeps
- ICMP echo request
SYN scans
- Only sends the initial SYN and waits for the SYN-ACK response. Very quick and hard to detect because the 3-way handshake never completed
ACK scans
- Useful in getting through router based firewall rules if it allows established connections.
FIN scans
- Sends packets with only the FIN control bit to bypass firewalls
UDP scans
- Sends packets with an empty payload with the exception to some ports
  - Application appropriate payloads to ports (53, 111, 161, ...)
TCP seq prediction
- Useful in spoofing attacks.

Below are some useful examples

#Nmap defaults to common ports only

# Scan a single IP
nmap $targetIP
# Scan a host www.somehostname.com
nmap $somehostname
# Scan a range of IPs 192.168.1.1-20
nmap $IPRange
# Scan a subnet 192.168.1.0/24
nmap $subnet
# Scan targets from a text file list-of-ips.txt
nmap -iL $someTextFile

# Scan a single Port    
nmap -p $port $targetIP
# Scan a range of ports 1-255
nmap -p $port-range $targetIP

# Scan using TCP connect
nmap -sT $targetIP
# Scan using TCP SYN scan (default)
nmap -sS $targetIP
# Scan UDP list of ports 123,161,162 192.168.1.1
nmap -sU -p $comma_delimiter_ports $targetIP

# Detect OS and Services
nmap -A $targetIP
# Standard service detection
nmap -sV $targetIP

# Save default output to file
nmap -oN outputfile.txt $targetIP
# Save results in a format for grep
nmap -oG outputfile.txt $targetIP
# Detect Heartbleed vulnerability
nmap -sV -p 443 --script=ssl-heartbleed $targetIPSubnet

Defense

Close all unused ports
Utilize stateful packet filters
Use proxy firewalls
Utilize IDS
Inspect logs for connection attempts

Use of netstat for checking open ports

netstat is available on Windows and UNIX machines to determine which ports are in use and their associated applications.

On windows, you can use a GUI application called TCPView to monitor port activity. The two basic commands on windows are as follows

Shows ports and associated process ID
netstat -nao
Shows EXE and DLLs associated with ports
netstat -nab

Unix machines by default give more information than their windows counterparts. Use the following commands to check for ports.

Show ports and associated process IDs and program names
sudo netstat -- P
To get full detail run
sudo lsof -i
Run this command to get more information on a particular PID
sudo lsof -p $process_ID

Windows guide to disabling services using admin PowerShell
PowerShell

kill the process

wmic process $process_ID delete

disable the service

sc query
sc stop $service_name
sc config $service_name start= disable #inlcude the space

Linux guide to disabling services. Youll need to edit the xinetd file and rc files.

#comment out lines
sudo nano /etc/inetd.conf
#add "disabled=yes"
sudo nano /etc/xinetd.d
# disable service
systemctl list-units --type service
systemctl disable $service

OSX guide to disabling services

# list of current services aka daemons
launchctl list
# stop the service
sudo launchctl stop $service_name
# remove the service
sudo launchctl remove $service_name

Takeaways

Whois

Remember attackers can leverage who is information to orchestrate an attack.

Contact Social engineering, deceiving users into giving up useful information
Phone Numbers War dialing, find unsecured modems
Postal Address Wardriving, finding unsecured wireless access points or poor physical security
IP Addresses Scanning

DNS Dangers

Remember if you don't correctly configure the DNS an attacker can gather internal IP addresses to start probing.

Zone Transfers Only allow zone transfers on your secondary DNS
Split DNS Split your DNS into external and internal

Web searches and Tools

Remember attackers can use not only your website but sites linking to yours as information about your environment.

Website Contact information & sensitive documents
Pipl & Pushpin Allows attackers to find people in your organization, locate them, exploit wifi systems or your people via social engineering
Shodan Check shodan frequently as a reference to your network and what the public knows about it
Google Hacking Use google to find sensitive information before the bad guys do.

Remember once its posted online it's online forever. Tools like web-archive keep a history of your website and all the changes you make.

Port scanning

Remember to close all unused ports and disable and remove all un-needed processes to those ports.

Nmap Used to map your network and check ports
Ports Any open port raises risk for intrusion

One of the main cyber-risks is to think they don’t exist. The other is to try to treat all potential risks.

Surveillance is going to happen, and there is not a lot you can do about it. Do your best to harden your system and make the correct configurations and do your best at handling real threats.

If this has been helpful to you, please support this blog by buying a coffee

Lessons Learned in Incident Handling

Dallas Baker — Wed, 25 Mar 2026 02:12:07 +0000

What happened and how can we improve our capabilities. Immediately after the system is back online in production start developing a follow-up report.

While drafting this report, the lead on-site incident handler should be the only one to write and supervises what is to be in the report. Everyone part of the incident should review the draft and sign off agreeing to its contents. If one should strongly disagree they can submit their version of the events, and it will remain part of the incident record. Make sure to include all incident forms completed during the incident. Within two weeks of resuming production have a meeting to discuss what happened and what the team learned from the incident. This meeting is also the time to review what the team could have done differently or improved for next time. Take time to finalize the report and provide an executive summary.

I hope this series in incident handling as helped you understand the correct process in handling incidents and encourages you to read other posts on real conflicts and how the method of controlling that incident provided an excellent service to both the business and its customers.

If this has been helpful to you, please support this blog by buying a coffee

Cheers! Happy threat hunting!

Recovery in Incident Handling

Dallas Baker — Wed, 25 Mar 2026 02:11:27 +0000

Back to business, as usual, is the goal in the recovery phase of incident handling. Putting systems back into production in a safe manner is essential. Restore the order and verify that the operation of the system is successful and running normally. Ask system administrator for baseline documentation. Request test plans and after incident handlers have tested the system the business unit should be instructed to retest the system for validity.

When to put the system back in production is always a good question, but unfortunately, this decision will come from the business unit. Still, give your recommendation, and it's ideal to do this when you can monitor the system without heavy user usage.

Monitoring

Once the system is back online, continue to monitor the previously affected system for backdoors that may have escaped detection. Revert to the identification phase to identify old or new signs of an attack. Use an IPS system to your advantage and even add a custom rule that can be triggered as attackers like to use the same attack vector. Continue to check OS and application logs frequently.

Don't rush this step because just in case you missed something or was unaware of a potential hole in the system you are likely to contain and eradicate the threat before damage occurs.

Lessons Learned

If this has been helpful to you, please support this blog by buying a coffee

Eradication in Incident Handling

Dallas Baker — Wed, 25 Mar 2026 02:10:50 +0000

With the bleeding stopped, the goal of the eradication phase is to rid the system of any artifacts created by the attacker. Determine the cause, symptoms, and how the attack executed. Use the information gathered during the identification and containment phases. These are important because many security professionals and system administrators take the shortcut of reinstalling the operating system and applications from scratch. While it is true that the malicious code can no longer run the same attack vector is still prevalent. Someone with network and forensic skills should take on this step in the process as there is no substitute for raw experience. In software engineering, there is a concept of pair programming in which a junior level engineer will work with a senior. This concept can be applied in security to give those with no experience the opportunity not only to learn but gain the skills needed if and when an experienced professional is not available.

Restoring from backup

If a recent or semi-recent backup is available, you have a chance to restore any lost data while minimizing the time required to configure and redeploy the system. When choosing a backup chose one before the system was compromised. When using a backup to restore the system be sure to apply any patches and fix all vulnerabilities that allowed the incident to happen in the first place. You don't want to be the hero, and then a few hours or even weeks later the same incident occurs.

Removing malware

If you are not able to restore the system from a backup your next option is to clean the system. Cleaning is not the most recommended a, but the business may not have another choice. Using antivirus software to rid malware can be very easy if the vendor has analyzed the malware. Removing viruses or other malware that do not have signatures may be an arduous task to complete. You'll need to monitor network traffic, services running, look for recent registry changes and files. If you encounter a rootkit you need to rebuild the system from scratch as the integrity of the operating system itself is lost. If you were successful in removing all malware make sure to verify all patches deployed to the system prevent the same attack from happening. I would like to reiterate that although this is a solution, encourage the business to rebuild the system from scratch.

Play Defense

Before going back into production implement additional protections to prevent future attacks on the system.

Apply firewall rules
Move the system
Change the DNS
Apply patches on similar systems and harden the system with behavior-based endpoint protection when possible

Analyze

Nessus and Rapid7 offer excellent penetration testing tools that can identify weaknesses in your systems. Identifying these weaknesses before an attacker gives you the opportunity to have security measures in place to prevent an attack. Other tools like NMAP can be used to determine open ports that were unaware to you.

Remember to check other systems because attackers often try and use the same exploit on multiple systems.

Recovery

If this has been helpful to you, please support this blog by buying a coffee

Containment in Incident Handling

Dallas Baker — Wed, 25 Mar 2026 02:10:12 +0000

In the military when a fellow service member is injured the goal for a combat medic is to stop the bleeding. In information security the containment phase is no different we want to isolate the threat to prevent the attack from spreading to other systems or causing more damage.

The containment phase has four main steps to be a successful containment. They are preparation, short-term containment, back-up, and long-term containment.

Preparation

Upon declaring an incident assign an incident handler to assess the situation. Secure the area and have incident forms on hand on site. Survey the area for wires, telephones, and wireless devices. Incidents start before you arrive onsite so survey what everyone saw, heard, and did. Threats can rapidly change and so don't treat things as time zero. As an incident handler validate the Category, Criticality, and Sensitivity of the threat.

Category

Denial of Service
Compromised information
Compromised assets
Unlawful Activity
Internal/ External hacking
Malware
Email
Policy Violations

Criticality & Response times

Incident impacts critical systems / 1 hour
Incident impacts non-critical systems / 4 hours
Possible incident, non-critical / 24 hours

Sensitivity & Who to inform

Extremely Sensitve / CSIRT & managment
Sensitive / CSIRT, managment, system owners, & operations
Non-sensitve / Employees

Company policy may advise different response times or who to inform of an incident

Always

Notify your management
Decide form of communication (email, phone, or in person)
Assign a minimum of two people
Create an entry in the incident tracking system
- CyberSPR is a great tool (Enforces need-to-know and all data is hashed and encrypted)

Tips

Keep a low profile
- Don't use tools like ping, traceroute, or nslookup
Don't tip your hand to the attacker
Maintain standard procedures
Document

Short-Term

The goal here is to isolate the threat as quickly as possible without changing the compromised data on the system. We want to keep the systems drive image intact until a backup of the image can be performed. This image allows us to validate the threat and have evidence of the incident. Some quick solutions may be to disconnect the network cable, kill the power, applying filters on network devices like firewalls or by isolating the machine on the switch port. Because most attackers are targeting a particular IP address a more complexed solution would be to change the DNS name to another IP address pointing to a secure system, so your users are not affected. This machine could also serve as honeypot so you can gather more evidence and possibly use something like WordWebBugs to track the attacker. However, if you can not contain the threat without denying access to legitimate users then make sure to advise someone in the business unit that is responsible for the system.
In some cases, the business unit may not approve your request to drop the system. When disapproval happens, it's then your job to provide the owner of the risk and reasons why it's wise to cut the system from the network. However, the business has the final say in this matter so look for other avenues in containing the threat. Deploying a new secure system or whitelisting access to the system may be some options. For external attacks like packet floods, bot-nets, worms, or spam consult with your ISP in assisting you in identify and containing the attack. ISPs often keep network and system logs that can add to your evidence. ISP most of the time are willing to help you so they can make improvements to protect other customers on their network so keep a close relationship with them.

Creating images

One of the most common errors in this phase is not creating working forensic images. The initial model should have both memory and the filesystem. Sometimes system administrators fail to perform regular backups of the system and data on these systems could be irreplaceable and mission critical. If you must perform actions on the system before backing it up then document everything you do such as commands and the responses to those commands. In an ideal situation, you want a binary image of the system as this gets everything including deleted or fragmented files. DD is a favorite tool in UNIX operating systems and most cases preinstalled. For windows, there are many free alternatives at your disposal like FAU. For analyzing memory Rekall, a google maintained project is a great solution.

Best practice is to use hardware tools like a drive duplicator. These tools allow you to make copies with ease and you can even introduce write blockers to create read-only copies that will be more valuable in court. When using hardware tools make sure that the copies are in binary and the drive used as the copy has at least 10% more space than is needed for the image.

Afterward, acquire logs and other source information to determine how far the attacker may have gotten. Review logs of neighboring systems and ultimately make recommendations for longer-term containment. The business will always have the final say if the system stays down or if it is to continue operation. Sometimes, the risk may be worth it to the business but include your recommendations in a signed memo to the business inforcing them to acknowledge the risk of the continued operation. Suggest a longer-term containment until the eradication of the threat.

Long-Term Containment

The idea here is to apply a temporary band-aid to stay in production while you build a clean system during eradication. There are many avenues for approach here, but the most common is only to patch the system if the attack was from using an exploit. If patching is not the best option then using an IPS or snort rule may be a practical option. Remember to remove any accounts and kill all processes used by the attacker. Before moving forward apply firewall rules and or modify your access control list to the system. You may have patched the system and initiated some additional security like firewall rules your job is still not yet complete. You still need to eradicate the threat entirely. Keep system administrators informed on your progress and never fault anyone during the investigation as this may ruin avenues in your research, and your assumptions may be wrong. Assuming makes an ass out of you(them) and me(you).

Takeaways

The next step after containing the threat is to eradicate it but let us review the process of containment.

Prepare for containment
- Determine the category, criticality, and sensitivity of the system.
- Contact your managers and support
- Don't let the attacker know you're on to them
Get the system offline if possible
- Unplug the power source
- Disconnect the network cable
- Apply firewall rules
- Modify your DNS
Create system images
- Create binary images of the system
- Use hardware tools if you have them
- Use tools like rekall if the system can not be taken offline
- Record logs from neighboring systems
Long-term containment
- Apply patches
- Patch neighboring systems
- Apply firewall & ACL rules
- Remove user accounts
- Kill processes
- Insert IDS systems

Eradication

If this has been helpful to you, please support this blog by buying a coffee

Identification in Incident Handling

Dallas Baker — Wed, 25 Mar 2026 02:09:36 +0000

Identification phase of incident handling involves detecting security incidents. Most detections will come from your security appliances like firewalls or intrusion detection systems (IDS). People can also be your eyes and ears, and with adequate training, they can be aware of security threats and whom to report.

Before we dive into how to identify incidents we need to know what to do if and when there is an Incident. Who is in charge of the incident, who do we alert, and most importantly when to alert and when to keep watch. Everyone should know of the classic story of The Boy Who Cried Wolf and if you have not its a story of a boy who was tasked to watch a herd of sheep and to alert the town if there was ever to be a wolf. The boy would get bored and cry wolf, and everyone would react and come to assist but when they arrived there was no wolf. When the wolf did come, and the boy cried out for help, no one came to the rescue. So I'm not saying to cry wolf but be willing to alert early and don't be scared to declare an incident. Even if there is not an alert, you still help the organization by giving the team the opportunity to learn in determining when there is an actual threat so treat this as a training opportunity. Take note that for an incident to form there needs to be a constant stream of information or events so be sure to provide these indications and warnings to validate your claims. Upon alerting for a possible security incident, it's ideal to assign one person as the primary incident handler and another person to assist him/ her to aid in communication and gathering of evidence. Make sure the handlers know which systems need to be validated and what needs to be documented so, in other words, do not leave your handler asking questions upon arriving and starting the investigation. The most crucial step is enforcing a need to know policy and I couldn't possibly say this enough because the majority of the time what you think is going to be the case turns out to not be the case. This change in assumption is widespread, and rumors spread faster than wildfires. The last thing you want for your organization is a news article publishing false claims about the events that took place. On another note, not enforcing this type of policy could hurt your investigation by alerting a possible inside threat and in return ruins your research and possible loss of evidence. When communicating during a potential security incident always use secure forms of communication. Rely on phones and encrypted email, but it's best practice to deliver in person and keep notes on hard copies.

Where

Although identification can occur anywhere in your network here are the most common network zones for gathering events.

Internet perimeter

Firewalls
IPS/IDS
Honeypots
DMZ

Host perimeter

Local Firewalls
Local IPS
Port sentry tools

Host Detection

Endpoint Security
File integrity tools
Help Desk ticket from user noticing strange behavior of the system

Application detection

Application generated Logs

I will go over clear examples of each later in the series, for now, know these are the systems that will generate information for us to analyze. In the ideal world, you want to identify and contain all threats at the Internet perimeter stopping threats from getting to your internal network. Unfortunately, attacks are more sophisticated and therefore detected after the fact. Please note that its impossible for these systems to recognize every attack or possible threat so as a system administrator or analyst you should know what natural looks like and look out for anomalies. Network spikes increased traffic, an abnormal number of failed login attempts to a particular system, or a user logged in on a system that shouldn't be are all examples.

What

So a system administrator or security analyst what are you exactly looking for when trying to identify a potential incident? In short, you are looking for the following unusual things.

Processes and services
Files
Network usage
Scheduled task
Accounts
Log entries

Start with network connections is ideal when determining where to start. Then work through processes and services associated with those connections. In Windows a tremendous free tool used for mapping ports with the associated program is TCPView.

See my post on windows for extra tools that will aid you past windows built-in capabilities.

To get a detailed understanding of identifying unusual things like Scheduled task see my post on how-to-find-anomalies.

HOW

So you've identified a possible threat or compromise on your network, and now you might ask how do you assess the situation. That's a great question and start by asking yourself the following questions. Do you have enough evidence to support your claim? Is it possible that the potential threat is a reasonable mistake? When I mean mistake ask your self-things like; Is there a misconfiguration or is it possible the user might not be aware they are trying to login in the wrong domain? What are other possibilities? It's a great idea to start documenting your evidence and collaborate with your team to see if they have encountered something similar or if there is a routine pen test.

Assess the situation

When looking at the situation, you need to determine how considerable damage could affect your organization. Executives will be asking questions like if there will be possible data loss or how the system will change and how this will affect business.

Common questions to have answers to

How widely deployed is the affected platform or application
What is the effect of vulnerability exploitation or if a vulnerability is present
What is the value of the systems impacted so far
What is the worth of the data in question
How is the vulnerability exploited
Is this a publicly available exploit

Risk assessment

When answering the following questions, it's a good idea to assess risk concerning the incident. A widely deployed system across the network can be terrifying in contrast to a custom internal application for a team. The larger the deployment, the harder it is to contain and therefore it poses a higher risk to your network and data. Regarding the effects, you need to know if this is a denial of service, surveillance, information compromise, or root/admin user account compromised. The type of threat is essential to know not only for risk assessment but will be needed later in the containment process of incident handling. Determining the value of a system will help you better assess how much of a risk the threat is. The thing to think about here is what types of data are on the system. Systems with sensitive data pose a higher risk than those with publicly available information. Where the threat is coming from is good to know as this will help with successfully containing the danger promptly. If the executed exploit didn't originate from the internet, then containment can be isolated on the LAN vs. installing firewall rule from the internet edge of your network. If the threat is an exploit check to see if this exploit is available to the public. Most of the time public available exploits contain documentation on how the exploit works, which systems are affected, and how to patch these systems. If there is an exploit and public obtained information isn't available, you may be dealing with a zero-day exploit, and then the stakes are severely raised. Lenny Zeltser has prepared an Initial Security Questionaire for responders that may be very helpful in this phase in the process.

Establish and maintain chain of custody

Remember to document everything and never delete any files until the finalization of the case. It's recommended to even then keep these files as evidence for future legal matters. A policy for a retention time frame should be approved by legal. Evidence should always be in the hands of one person, and no one else should tamper with the evidence. HANDS OFF! Get a signature from law enforcement if and when you turn over evidence.

Takeaways

Know your network and know where to look for anomalies
Know your system administrators and establish a baseline for your systems
Use tools to your advantage to identify threats
Ask questions and build a case by documenting evidence
Perform risk assessment and gather as much information as possible
Establish a chain of custody

Remember the more you document and information you gather will help see the incident through to the end.

Containment

If this has been helpful to you, please support this blog by buying a coffee

Preparation in Incident Handling

Dallas Baker — Wed, 25 Mar 2026 02:08:52 +0000

The goal of the preparation phase is to get ready to handle incidents.

Security professionals will spend most of their time in the preparation and identification phases of the incident handling process. I'll be covering People, policy, data, software, communications, supplies, environment, and documentation of the preparation phase.

People:

The most overlooked aspects of security and attackers know this and target your people. Attackers use anything from social engineering to phishing campaigns, and training can be a big help in preventing these types of attacks. Annual training tends to be ineffective, and while it may be common sense not to click the link in the email or give sensitive information over the phone, we all tend to want/need to help people, and unfortunately, attackers use this against us. Imagine getting a call from someone who has a baby crying in the background, and they are saying their significant other has requested they call and update the billing or personal information on their account. They give you valid email, phone number, or even call from the phone number on the account and they seem to be who they say they are. Although you shouldn't change these without a two-factor authentication method like a text message you see they called from their number and knew some details of the account you make the changes so they can get on with their lives and attend to the baby. The call was spoofed, and the baby was actually a youtube video, and you are now a victim of social engineering. While this sounds silly, it happens more often than you would believe. At a minimum, your organization should undergo quarterly training and testing. Call your employee's via social engineering or utilize a phishing campaign. Tools like spottlkit and phishme are excellent ways to create phishing campaigns with the ability to track the results. Find more information at Sucuring the Human

Policy:

Your organization should establish policy and warning banners. Having these in place will support your monitoring activities and back you up in a court case. You'll need to consult a local legal counsel if you are in Europe or in a country that implements similar policies on data monitoring you'll need to ask a local legal counsel to advise you on such matters because the European Data Privacy Directives forbid you from monitoring your data. Have a legal team review this banner and approve it in writing.

Your banner must advise users of the following.

Access to the system is limited to company-authorized activity.
Any attempt at or unauthorized access use, or modification is prohibited.
Unauthorized users may face criminal or civil penalties.
The purpose of the system may be monitored and recorded.
If the monitoring reveals possible evidence of criminal activity, the company can provide the records to law enforcement.

When to involve law enforcement:
Most organizations maintain secrecy until they must notify law enforcement; however, that's not always the best policy. There are times when you must notify law enforcement, times you need to inform the public, and times when you have the option.

Reasons you must notify law enforcement

Threat to public health or safety
Substantial impact on third-party contracts
Legal requirements based on industry
- FDIC, OCC, or fed reserve for finacial companies

You need to notify the public of breaches concerning PII or PHI

Over 45 states have breach disclosure legislation
Even if you don't operate in a state that enforces this policy if you have a customer who resides in a state that does then you must notify them of a breach.
The US Federal Government and other countries are working on similar legislation

Optional Reasons

Beneficial to the criminal discovery process
To be a good corporate citizen

Reasons not to involve law enforcement

Some might want to resume business after an incident, and by requiring law enforcement, this might have an adverse effect. Law enforcement may request to keep the system open and let the hacking continue to gain more evidence, or they may seize your equipment that is crucial for business. For more information concerning law enforcement visit SANS's Interfacing with the Law FAQ.

Outside Policy

Your organization should establish a policy for outsiders notifying and for dealing with incidents involving remote computers belonging to business partners, your company, employees, contractors, or other employees that are not full-time. These policies are essential to have in place in the event of a compromised device containing business data of an employee who works from home. Some things you should think about are how will you decide to back up the data and of a compromised system. How will you resolve the issue? The employee may have sensitive personal data such as photos or tax records. You should also have a VPN usage policy that includes a banner notifying the employee that systems connected to the VPN services are subject to remote search.

Documentation

Even during a mild security incident times can be stressful, and this leads to mistakes. Practice communicating and note-taking under stress. When you are testing your organization, don't always inform your SOC analyst it's a test. This idea is an excellent way to evaluate their performance during the trial and allows for better communication and documentation during a real security incident. Documenting the events during a security incident is vital for incident handlers. Remember to slow down and take notes on everything even make a reminder that you are moving to fast to take notes. This reminder will allow you to slow down and begin documenting what's taking place. Handwritten notes are best in most cases as these are hard copies and convenient. Handlers can create digital copies at a later time. Handwritten notes can be handy in court cases, and attackers cannot steal or destroy them. Remember if you are going to fast to take notes, your going to fast.

Tips for great documentation

Using a bounded notebook with page numbers
Answer the who, what, when, where, why, and how
Record all of your actions
Date and timestamp each entry
small audio or camera can be used to your advantage

Environment & Communication

Communication and a healthy environment are critical in any department of an organization and are no different in security. If we as security professionals do not invest in contact with our managers and directors the only time incident handling is appreciated is when there is an incident that scares management, and the team handled the incident well. Getting and keeping management and system administrators support is an uphill battle in most cases but here are some tips to improve communication with your managers and administrators. At the minimum develop monthly, quarterly, and yearly reports on brightly colored paper with eye candy graphics. Management loves colorful, easy to follow, statistical reports. Managers will generally inform directors who only care about numbers, and the high lights so don't over complicate the story with technical details. If you have a quiet month, then focus your report on recent events in security and how your team is working diligently on preventing similar threats from happening in your company. You want to be able to sell your team in a way that gains support from your executive leaders. Selling your squad well can increase funding and awareness of security threats and your efforts to protect the company and who knows you may even become the department of the month.

Building a team

Hand selecting a team of individuals is the best approach here. Don't let other managers, employees, or other factors influence your decision on deciding the best fit for your team. Raw technical skills alone may not always be the best determining factor. I would suggest building a core team of individuals who have the technical skills needed to be the first incident handlers and a larger group comprising of different skill sets. Make sure to include subject matter experts in legal and public affairs. These guys may not be very technical, but they know their way around regulations, policies, and compliance.

Tips for a solid team

Security both physical and computer
Highly technical individuals with experience in forensics and malware analysis
System Administrators
Network management
Legal counsel
Human resources
Public relations
Disaster Recovery professionals
Union rep -if you are a union shop

It's wise to keep a close relationship with help desk, network team, and system administrators.

Software & Supplies

If you have ever attended a sporting event, you've probably noticed how many support personnel are there on standby with supplies and tools to aid a player who may get injured during the game. In information security, we practice the same concepts just different tools and supplies. One highlight here is the GRR Rapid Response tool maintained by Google Inc. GRR is a free tool that runs on any operating system. The software contains the following features

GRR Features

Remote memory analysis
Python-based agent
Powerful backend
Detailed monitoring of clients
Pull in-depth forensic artifacts from multiple systems
Async functions

Aside from GRR its useful to keep on hand Binary images of tools and Forensic software.

useful tools

DD
Netcat
NCAT
Safeback

Forensic Software

Sleuth kit - Free sliethkit.org
Autopsy - Free sliethkit.org
Guidance EnCase
AccessData Forensics Toolkit
X-Ways

It's suggested to keep USB binaries or CD-ROMs because a rootkit installed on the OS changes the integrity of the tools and therefore cannot be trusted. You also don't want ISO packages because an attacker could manipulate the libraries used. Always use a binary image and keep live bootable images of Linux for forensics. Windows tends to alter the hard-drive contents and could corrupt or destroy critical evidence. The SANS investigative Forensics Toolkit better known as SIFT can be helpful to jumpstart your toolkit.

SIFT includes

Sleuth kit
log2timeline
wireshark
volatilty
ssdeep and md5deep
etc

Additional supplies

USB 16gb
External Hard drives with USB2/3
Ethernet Tap
Ethernet (cross-over straight-through)
USB and serial cables
laptop with multiple OS
- Windows and Linux
SSD and additional Ram
call list
cell phone
notebooks
incident forms
change of clothes, deodorant, aspirin & antacid (never know how long an investigation may take)
jumpers
flashlight
screwdrivers
RJ-45 connectors
Tweezers
business cards

Remember always be ready and alert for when an incident occurs you won't have time to prepare!

Next step in the Incident Handling process is Identification.

Identify Threats

If this has been helpful to you, please support this blog by buying a coffee

Incident Handling

Dallas Baker — Wed, 25 Mar 2026 02:07:50 +0000

Peter, I can't eat red lobster. No seriously, I prefer the blue ones they are not as snappy. If you have landed on this page, you might be curious to know what Incident Handling is or how to address security incidents in your organization correctly.

Incident handling is a plan of action for dealing with intrusions, cyber-theft, denial of service or any other information security-related events. Most people assume a security incident as an intrusion but don't forget insider crime, intentional or unintentional events that may cause loss of data or service. Other things to consider are intellectual property like trade secrets, patents, copyrights, and trademarks. The critical point in incident handling is to act upon the security threat, and it will not matter how great of a plan you may have if your watching things happen. Rember time is always against you so act quickly to minimize the damage. Your method of action must also comply with the laws set forth by your local, state, and federal governments.

Before we dive into the actual handling process, I want to clarify what an incident, event, and alert are. Alerts build up to an event and events lead to an incident. Typical incidents include unauthorized use of an account, unauthorized use of system privileges, or execution of malicious code that destroys or exfiltrates data. Company policy will determine the differences between alerts and events, but incidents almost always imply harm or an attempt to harm a computer system. This harm may not still be what you expect because things like floods or fires are considered an incident.
On the contrary, an event is any observable occurrence in a system and or network. Some examples of activities include but not limited to system boot sequence, system crash, or packet flooding. You might have thought a packet flood to be an incident, but this may very well be legit traffic. You're not receiving a denial of service attack you are merely the popular guy on the street. Events however are, they tell a story, and so you should log and record these events. Having this information in multiple places helps legitimize your claims if you happen to be in court. Two is better than one.

The six stages of incident handling are; Preparation, Identification, Containment, Eradication, Recovery, and Lessons Learned. You can call these steps what you like; however, these are the industry standard terms set by SANS. It helps me remember them using the acronym "Peter I Can't eat red lobster." When an incident happens, it's wise to take time to think. It's important to act quickly but do so that you minimize mistakes. Incident handling is very much like first aid and errors can be life-threatening or in this case, one could ruin evidence. When an incident happens, follow your plan, document everything, and don't skip any steps. NIST has developed a comprehensive Incident handling plan at the link below.

NIST Security incident handling guild

Before we move into detail for each step of your incident handling plan, remember to share experiences with other organizations and other teams. Bad guys always share information, and if we as security professionals don't do the same, they will still have a step ahead of us.