First email from Data
Based on the intel below, here are some other thoughts:
1. Familiarity with wevtutil (windows command line event viewer) and the GUI event viewer will make their lives easier. Since server 2003, MS has made it a requirement that ‘if you can do it with the GUI, you can do it with the command line’. So there’s always a command line equivalent… somewhere. It isn’t always convenient.
2. Tunnelling might be something worth touching on. Can be done easily with a few Linux VMs and SSH to teach the concepts.
3. Malware detection. I can help with that. Some general tips include:
a. Windows:
i. Processes & process identifiers.
1. PIDs get bigger the newer the process. Some tools (sysinternals’ process explorer) will show you actual start time. Procexp will also query virustotal for you and see how malicious each binary is (presuming you’re connected to the internet)
2. Depending on the version of the OS (2k, XP, Vista, etc), you can tell what PIDs started with the boot of the machine. Also good to know what services come stock with which OS.
3. Verifying running processes are good is sometimes tough. Might want to consider sysinternals’ listdlls (with the signature check turned on) to see if any of the running processes (and their loaded libraries) fail to pass a signature check. Gives you a place to start. Presumes that malware authors don’t digitally sign their malware and that the malware landed on disk somewhere (i.e. isn’t just running in memory).
4. Look at the startup items that run on the PC. Autoruns from sysinternals is a good start.
ii. Ports
1. Depending on the OS you can tell what was likely a machine-generated ‘random’ port and what wasn’t. XP had a very narrow range of ‘random’
2. Looking up port numbers online might give some clues. Many online port dictionaries save info about malware, too.
3. Netstat is your friend. Not as powerful as netstat on linux, but still pretty good. Sysinternals’ tcpview is handy for seeing who is being chatty.
b. Linux
i. Processes & PIDs
1. Listening server processes usually fork off child processes (e.g. ssh). Orphaned processes suggest that the listener (legit or otherwise) may have been killed or subverted
2. Ps/pstree will show you the process tree good for finding processes that don’t belong (see #3)
3. Knowing what processes SHOULD be present in your specific build of linux is important. Auditd is great for redhat but isn’t as common on Ubuntu… Also, the OS version can change things. Just like XP vs win10, Ubuntu 11 will likely have less running than Ubuntu 15…
4. Lsof shows you loaded libraries for a given process. Rpm can check a package’s signature and show you what package a file came from. Presumes that malware authors don’t install from signed packages. Presumes that the malware landed on disk somewhere (i.e. isn’t just running in memory).
ii. Ports
1. Grep /etc/services for ports that the system knows about. Might give you some clues. If you see traffic on port 80 and httpd isn’t running, then you might have something fishy going on.
2. Netstat is good for cross-checking. For example, if there’s an active connection with a PID that doesn’t show in ps, you may have a rootkit