you’ll go open a screen or tmux session on your target, run a tcpdump in the background and detach and continue your IR, and when you’re done, you’ll bring that pcap file to your system later on for further analysis and as potential evidence. You probably have your own copy of tcpdump to capture packets. I have both tcpdump and tcpshark in that toolkit :) Use cases This (mostly) eliminates the risk of a malicious actor pwning one of your core libraries or even worse, backdoor it.
To combat this issue, I’ve built quite a few tools for Linux (both amd64 and arm7- arm64) with static linking, so the binary can be run directly w/o any need for a shared library. So it’s a bit tricky to SSH into a compromised host and copy your “helper” scripts and tools, hence all of them might get leaked quite easily. so if the attacker replaces readline with a backdoor-ed version, bash would have no idea and you’ll have the easiest keylogger in the world. If you want to see an example of that, look at how bash is linked against readline.so, meaning each command that you pass through your bash terminal, it gets through readline library. When you’re performing Cyber Incident Response on a host or a container, it’s always a good idea to turn on a packet capture in the background while you’re responding, recovering or even remediating, since more often than not those packets will come handy as evidence.ĭepending on what OS you’re working with at the time, you use a different tool for capturing packets, and that tool, and the way its built, actually matters. If you have proper packet processing, you’ve got a powerful asset in your IR and 0-day detection toolkit. Packets don’t lie if they’re stored properly, and they paint a good picture of what happened if there’s enough metadata surrounding it. I know that’s probably one of the most depressing things you’ve ever heard, but that doesn’t make it less true (͠≖ ͜ʖ͠≖)
As a cyber defender and a DFIR analyst, network packet captures are one of my best friends.
0 kommentar(er)
