> Since I wasn’t root and couldn’t install any tools (guess I could have copied a netstat binary across)
If you have the ability to write anywhere to disk (e.g., even /tmp, /run), dropping a copy of Busybox (a statically linked, minimal clone of many of the base tools like ifconfig, netstat) has helped me more than once.
(I didn't have a working scp on a machine, and it was the ssh "gateway" to another machine that I needed access to. To jump to the next machine, I needed to run either ssh or nc, both of which were defunct (the HDD was dying). Copied busybox over for nc, and it worked like a charm. I had to write a small python script to transform the binary into a printf command to write it out to disk, as essentially nothing but bash builtins worked due to the condition of the disk. Had a minor panic attack when I realized I needed to chmod +x it, but chmod still worked. In hindsight, I think I could have set the umask prior to the printf to avoid that step.)
I like Bash's TCP thing. First time I saw it thought a coworker was pulling my leg. Since then I've used it in a few places like talking to a metrics daemon on localhost, or just debugging various issues. The most fun thing is to show it to others as almost everyone is surprised about it.
"I had to write a small python script to transform the binary into a printf command to write it out to disk, as essentially nothing but bash builtins worked due to the condition of the disk."
Why not create a tmpfs directory over some existing directory? Why try to write to disk when the disk is known to be malfunctioning? Then send the static binaries needed to the tmpfs directory, e.g., using netcat. Perhaps I have misunderstood the problem.
Many years ago, I once tried a pre-packaged, well-regarded, "system rescue live CD". When I tried to use it on a computer with a malfunctioning disk, the rescue CD would fail to boot. Apparently it tried to access the computers HDD during boot. I switched to using another less-hyped OS to boot from USB stick into RAM and encountered no problems rescuing the malfunctiong HDD. Oh well.
Unlike other Unix, Linux doesn't control its userland. net-tools (ifconfig, netstat, arp, route, etc.) was maintained by a separate person, was mostly a dead project (it has been revived very recently) and many scripts heavily relied on their interface (both input and output). To be able to push new features, kernel devs had to develop a set of tools to expose those features to users in a coherent way.
Only in GNU/Linux can it happen that core networking utilities like netstat, arp and ifconfig fall into neglect. Because no, they don't know any better.
Pro-tip: if you pop a shell, only use it to run your own dropper. Use locally available tools as little as possible. Automate your entire post-exploitation payload and cleanup and get out as soon as possible.
Reading this article is like reading about elite navy seals who storm an enemy outpost, get inside, and then get distracted trying to refashion a stapler they find laying around into a lock-picking device to open the safe.
It depends upon what one is trying to do, and what resources one has available, IMO.
If someone is actually working for an intelligence agency/criminal organization, or is part of an internal red team, then they have the time and resources to target specific classes of system, plan everything out, and build a package that will do exactly what they want against those specific systems, without any operator interaction.
Most pen testers don't have the time to do that, let alone do it well, and there's a good chance that anything automated that they hack together will miss something interesting either because the person who built the payload didn't expect it, or because blindly doing all of the things that would locate interesting information would involve sending gigs of data back to C2.
Knowing how to quickly improvise things like what's described in the article is super-helpful for the more generalized "see how you can misuse this system" type of pen testing.
netstat and ifconfig tend to be deprecated on Linux in favor of ss and ip. I do have to wonder if ss was tried, but still, the learning experience is quite valuable. :)
I've also had to deal with a lot of this 'security'. It really inhibits normal work so much that security is probably reduced.
Any machine should have tcpdump, netcat, lsof, strace as well.
If you want to make it more secure - well set permissions appropriately and/or use selinux/apparmor.
Hell, may as well put osquery on it as well. Why make life difficult for people to do their jobs?
At an interview I was asked how to diagnose a running program.
I mentioned strace of course, but they were also looking for gdb use. I've not had gdb on any prod machine for 'security reasons'. :-(
I wonder if ss was available? I'd recommend looking over "Deprecated Linux Networking Commands and their Replacements"[1]. In the case of netstat, `ss -a` is a good place to start.
Reminds me of an article shared a while ago on HN where someone deleted / and ended up with all binaries gone but still had a working bash session and the /proc fs. Can't find the link, sadly.
If you have the ability to write anywhere to disk (e.g., even /tmp, /run), dropping a copy of Busybox (a statically linked, minimal clone of many of the base tools like ifconfig, netstat) has helped me more than once.
(I didn't have a working scp on a machine, and it was the ssh "gateway" to another machine that I needed access to. To jump to the next machine, I needed to run either ssh or nc, both of which were defunct (the HDD was dying). Copied busybox over for nc, and it worked like a charm. I had to write a small python script to transform the binary into a printf command to write it out to disk, as essentially nothing but bash builtins worked due to the condition of the disk. Had a minor panic attack when I realized I needed to chmod +x it, but chmod still worked. In hindsight, I think I could have set the umask prior to the printf to avoid that step.)