4.6 Endpoint Assessment Tools & Malware Removal

4.6 Endpoint Assessment Tools & Malware Removal

Quick Answer: Three built-in commands do most of the first-line diagnostic work on a suspect endpoint. netstat answers "what is this machine talking to, and which process is doing it?" nslookup answers "is this machine resolving names correctly, or has DNS been tampered with?" tcpdump answers "what is actually on the wire?" Once a compromise is confirmed, the malware removal workflow runs quarantine → scan with updated definitions → review scan logs → remediate → verify → restore, with a rebuild-instead-of-clean decision point for rootkits and unknown-extent compromises.

Blueprint sub-topic 3.2 names exactly three tools — netstat, nslookup, and tcpdump — and sub-topic 3.6 covers malware removal. Both are hands-on tasks a Tier 1 technician performs, and both are best learned by running the commands rather than reading about them. Everything below can be practised on your own machine.

---

1. netstat — Active Connections and Listening Ports

netstat (network statistics) reports the endpoint's TCP and UDP connections, listening sockets, and routing information. It is the fastest way to spot a host beaconing to an unexpected destination or a service listening on a port nobody authorised.

Key switches

Reading the output

A typical Windows line looks like:

  Proto  Local Address          Foreign Address        State           PID
  TCP    192.168.1.42:51544     203.0.113.77:443       ESTABLISHED     4812
  TCP    0.0.0.0:3389           0.0.0.0:0              LISTENING       1044

Connection states worth knowing:

Tracing a suspicious connection to its process

This is the workflow the exam expects you to be able to describe:

1. netstat -ano and identify the suspicious foreign address and its PID.
2. Match the PID to a process: tasklist /FI "PID eq 4812" on Windows, or ps -p 4812 -o pid,user,cmd on Linux.
3. Inspect the executable's path and digital signature. A process named svchost.exe running from C:\Users\Public\ rather than C:\Windows\System32\ is a classic masquerading technique.
4. Record the finding, then escalate or contain — do not simply kill the process, because doing so destroys volatile evidence and tips off an active intruder (see Section 6.3 on order of volatility).

Baseline first. netstat output is only meaningful against a known-good baseline. Run it on a healthy machine of the same build so you know what "normal" looks like before you have to judge an incident under pressure.

---

2. nslookup — Querying DNS Directly

nslookup (name server lookup) queries DNS records directly rather than relying on whatever the operating system resolver has cached. It is the tool for confirming whether name resolution itself has been tampered with — the mechanism behind pharming, DNS cache poisoning, and hosts-file hijacking.

Common usage

The diagnostic that matters

Compare the answer from the local DNS server against the answer from a known-good external server:

nslookup intranet.example.com                 # what this host is being told
nslookup intranet.example.com 1.1.1.1         # what a trusted resolver says

If the two disagree, something between the host and the authoritative zone is lying. Investigate in this order: the local hosts file (C:\Windows\System32\drivers\etc\hosts or /etc/hosts), the DHCP-assigned DNS server setting (a rogue DHCP server can hand out a malicious resolver), the local resolver cache (ipconfig /flushdns on Windows), and then the DNS server itself.

A precision point: nslookup bypasses the hosts file, because it queries DNS directly rather than going through the operating system's resolution order. A name that resolves correctly under nslookup but still sends the browser to the wrong site is a strong indicator that the hosts file has been modified — a technique malware uses to redirect antivirus update domains to nowhere.

Two related notes: dig provides more detailed output and is preferred on Linux, and DNS query logs are a high-value SIEM source because most malware resolves a domain before it beacons.

---

3. tcpdump — Capturing What Is Actually on the Wire

tcpdump is a command-line packet capture tool. Where netstat tells you a connection exists, tcpdump shows you the traffic itself. It uses Berkeley Packet Filter (BPF) syntax — the same filter language Wireshark uses for capture filters.

Core switches

Filter expressions

Worked example — investigating a host suspected of beaconing:

sudo tcpdump -i any -nn host 203.0.113.77 -w beacon.pcap

This records every packet between the endpoint and the suspect address, with no name resolution, into a file you can hand to a senior analyst or open in Wireshark.

Operational cautions

• tcpdump requires root or the CAP_NET_RAW capability, because it puts the interface into promiscuous mode. An unprivileged user cannot run it.
• Captured traffic frequently contains sensitive data — credentials on cleartext protocols, personal information, session tokens. A .pcap file is evidence and must be handled with the same care as any other artefact (Section 6.3).
• Capture where the traffic actually is. On a switched network a host sees only its own traffic unless you configure a SPAN/mirror port or insert a network TAP (Section 3.3).
• Filter at capture time. Unfiltered captures on a busy link fill disks in minutes and are painful to analyse.

---

4. The Malware Removal Workflow

Blueprint sub-topic 3.6 covers scanning systems, reviewing scan logs, and malware remediation. The industry-standard procedure below is what an exam scenario expects you to follow in order — and the ordering itself is what is usually tested.

Step 1 — Investigate and verify the symptoms

Confirm you actually have malware rather than a hardware fault, a failing disk, or a misbehaving update. Genuine indicators: unexpected outbound connections (netstat), new autostart entries or scheduled tasks, disabled antivirus or Windows Update, browser redirection, unexplained CPU or disk activity, new local accounts, or files with a ransom note extension.

Step 2 — Quarantine the system

Disconnect the host from the network before anything else — pull the cable, disable the wireless adapter, or have NAC move it to an isolation VLAN. This stops lateral spread and cuts the command-and-control channel. Leave the machine powered on if an investigation is likely, since powering off destroys memory-resident evidence.

Step 3 — Disable System Restore (Windows) before cleaning

Malware routinely hides copies of itself inside System Restore points, so a cleaned machine reinfects itself the first time a user rolls back. Disable System Restore, remove the existing restore points, clean the system, and create a fresh restore point afterwards.

Step 4 — Update definitions and scan from a trusted environment

• Update the antimalware engine and definitions first, from clean media or a controlled network segment. Scanning with three-month-old signatures is the most common reason a scan comes back clean on an obviously infected machine.
• Scan from an environment the malware does not control. Advanced malware hides from a scanner running under the operating system it has already subverted. Use Safe Mode, a Windows Recovery / pre-installation environment, an offline scan such as Microsoft Defender Offline, or a bootable rescue medium.
• Run a full scan, not a quick scan. Quick scans check only common locations.

Step 5 — Review the scan logs

The blueprint calls out reviewing scan logs specifically, because the log — not the summary dialog — is where the useful information is:

• What was found, and where. A detection in %TEMP% is routine; one in C:\Windows\System32\ or in a boot record is serious.
• What action was taken. Quarantined, removed, and access denied mean different things. "Access denied" or "removal failed" means the file is still there and probably in use — treat the host as still infected.
• How many detections and of what family. Multiple unrelated families usually indicate the host was exposed for a long time, or that a dropper has been pulling down additional payloads.
• Whether items reappear after reboot. A detection that returns after a clean scan indicates a persistence mechanism the scanner did not remove.

Step 6 — Remediate

Remove or quarantine detected files, then clear the persistence the scanner may have missed: unwanted registry Run keys, scheduled tasks, services, startup folder entries, browser extensions, and unexpected local accounts. Reset credentials that were used on the machine while it was compromised, and patch the vulnerability that allowed entry — otherwise you have cleaned the symptom and left the door open.

Step 7 — Verify, then restore normal operations

Rescan with updated definitions and confirm a clean result. Re-enable System Restore and create a new restore point. Confirm real-time protection, the host firewall, and automatic updates are all back on — malware commonly disables them. Reconnect to the network, then monitor the host for anomalous connections for the following days.

Step 8 — Educate the user

If the entry point was a phishing email, a side-loaded application, or a USB drive, closing that behavioural gap prevents the repeat you would otherwise see within weeks.

---

5. When to Rebuild Instead of Clean

Cleaning is the default, but it is not always adequate. Rebuild from a known-good image when any of the following is true:

• A rootkit or bootkit is confirmed. Kernel- or firmware-level code can hide from and subvert the very tools you are using to check the machine.
• The extent of compromise cannot be established — you can prove something got in but cannot prove what it did.
• Removal repeatedly fails or detections reappear after each clean scan.
• The host held administrative credentials or sensitive data, so the cost of being wrong is high.
• Ransomware encrypted the system. Restore data from clean backups; do not attempt to clean and reuse the running installation.

The rebuild sequence is: preserve any evidence needed first, image or wipe the disk, reinstall from trusted media or a golden image, patch fully before returning the machine to the production network, restore data from a backup taken before the infection date, and reset every credential the host touched. Section 6.2 covers the containment, eradication, and recovery decision in full.