Also, you would have been labeled a script kiddie and laughed at for this kind of mostly automated hack in the late 90s.
Gosh, I miss those times when hacking was mostly for fun and challenge. Now it seems to be only for work, money or malice.
Also, you would have been labeled a script kiddie and laughed at for this kind of mostly automated hack in the late 90s.
Gosh, I miss those times when hacking was mostly for fun and challenge. Now it seems to be only for work, money or malice.
I don’t work in security, but I’ve always been very intrigued by it and have enjoyed some success in CTFs. Having said that, is automating stuff not a goal of every software engineer? DevOps has exploded in popularity; terraform didn’t exist in the 90s. Am I a script kiddie for using pre-built (and tested!) terraform modules?
As for the “mostly for fun” quip… OP is literally writing up a HackTheBox challenge, performed purely for fun. If you want something fun and security adjacent to play around with I can’t recommend microcorruption strongly enough; I really really enjoyed that.
Do you communicate with web servers using netcat? Do you open raw sockets and forge your own SYN packets? Do you compute cryptographic signatures with you pocket calculator? Do you write programs in Assembler instead of C or Python? No, because in most cases it would be a tremendous waste of time.
Why insist on others going through the same motions you did instead of just publishing your exploit or offensive security tool? Why would you reinvent the wheel if the problem has already been solved by someone else? (Unless for academic purposes.)
There is nothing wrong with tapping into the gigantic hive mind that is modern whitehat hacking. Today, we tend to go for the "standing on the shoulders of giants" approach instead hindering progress by gatekeeping our own achievements.
As someone who abandoned hacking two decades ago, I was really taken aback by that usage of a local web server to transfer shell scripts. What happened to the plain old copy and pasting of scripts through your existing ssh connection, for crying out loud? ;)
While sure, it was probably possible at this point to do that, I can think of a few really good reasons:- SCP doesn't always work, the SFTP/SCP subsystems can be turned off. This makes it unreliable. In practice, most targets will have it enabled but this could bite you when it doesn't.
- Copy and pasting a 130KB script is not always reliable either, especially if it contains shellcode (you get lovely session- or term-breaking binary data shoved into it). It can work in a pinch but it's less reliable than pretty much all your other options.
- There are categories of attacks that require an out of band connection to exploit, which means you want the server with your tools available somewhere anyways. If it's already set up, why not leverage it?
- You may not have the ability to reliably open a new ssh connection.
Conversely, you have to consider that HTTP traffic may be filtered on egress, monitored, etc.
In my experience, actually getting SSH into the system is typically unnecessary anyways.
Also, you would have been labeled a script kiddie and laughed at for this kind of mostly automated hack in the late 90s.
A script kiddie wasn't a script kiddie because they used scripts sometimes successfully, they were a script kiddie because that's all they could do. Most experienced pentesters I know use linpeas and similar scripts to see if there's any easy low-hanging fruit. It's simpler to do that as a quick check than to run down your own checklist each time. That doesn't mean that's where they stop.You know, like devs using boilerplate, or people coding using standard libraries, or using a presentation template.
Gosh, I miss those times when hacking was mostly for fun and challenge. Now it seems to be only for work, money or malice.
I'm not sure how you arrived there in this particular thread. Hackthebox and hackthissite and other similar challenge systems, the entire concept of CTFs (check out how many are at ctftime.org) are all for fun challenges to help people learn.and use tar to stdout, untar from stdin to transfer directories. It can even be compressed while archiving or at ssh level.
or rsync over ssh.