I managed to get a real shell afterwards but user.txt wasnât in the location shown by the locate command. Not sure if that was intended or another âuser manipulationâ, it was very late so I didnât reset the box to check again.
The user flag is where it should be. I suspect that if you arenât in the right account you canât see it.
Keep in mind, locate does a search in the updatedb database - it will only find files that are stored in the db. It is often not as effective as a find command.
For example find / -name "user.txt" 2>/dev/null would, in most situations be a better choice. (I have no idea if it would work on this box, I never tried it). File permissions can affect both.
Ok - so having tried this I might have a better idea what you mean.
Somethings to consider:
locate is (at least in my experience) really hit and miss. It frequently misses file on my local system because I dont keep the database up to date.
each user account has set privs, if the account you are in doesnât have privs to see the file, you might not be able to find it with other tools. Keep in mind what account is being used by which âexploit.â
If you use the second account via the first bit, the output is muddy so it isnât great for broad searching (targeted enumeration still works).
On this box, there is no need to hunt the flags. They are exactly where they should be.
@TazWake Edit: Posts were timed badly. Now you answered my questions, thanks.
Awesome - I think I understand at last!
Hopefully, we are communicating on the same frequency now
It is a crying shame that so many people think it is funny/clever to break the boxes for other people. I wish more Linux boxes set the immutable flag on the flags.
Got user, wasnât so much hard as it was I had never used this method before and couldnât find anything online about it. Thanks to @TazWake for walking me through the second half with the S** service trickery.
Onto root, from what I see on this thread this will certainly go over my head. I have 0 knowledge of reversing⌠should be interesting.
Been increasing the difficulty over the past 2 weeks, Unbalanced was a cakewalk but this is definitely my max.
Edit: Starting the 6 hr ghidra crash course lol wish me luck
@LMAY75 for scp you need a valid SSH creds to work. Otherwise it wonât as it comes with a part of SSH. Try NC or Pyserver for easy file distribution.
@LMAY75 for scp you need a valid SSH creds to work. Otherwise it wonât as it comes with a part of SSH. Try NC or Pyserver for easy file distribution.
No I ended up getting scp to work. It was just hanging at first.
Good suggestion from @sparkla - people often overlook how effective Base64 can be in transferring files between systems.
However if ssh from you to the box works, so should scp as it is basically the same protocol. If ssh works but scp fails, there is a good chance something on the box is broken.
SSH from box to me doesnât work as well. I suspect either broken or on purpose to prevent usage of nc (and enforce the intended route) in the early stage of foothold.
Rumour has it (and I certainly havenât even tried to confirm this yet) but SSH from HTB boxes to user machines is prevented.
You should be able to use SSH/SCP from your machine to this box though.
Couldnât spot the privesc, nudge welcome.
Its difficult to avoid spoilers. Iâd start with thinking about this as a compromised device, and looking for things the attacker might have done to allow themselves back in.
SSH from box to me doesnât work as well. I suspect either broken or on purpose to prevent usage of nc (and enforce the intended route) in the early stage of foothold.
This may be why your SSH isnât working from the box to your machine. It may not be. YMMV.
FYI if anyone is stuck on this. Edit /etc/ssh/sshd_config and change âPortâ to anything you want. SSH is only blocked on the standard port. I still wouldnât recommend leaving it enabled though, just start it when you need and stop it afterwards: systemctl start/stop ssh