Forensic Reconstruction
Okay so here's another puzzle I built and released some time ago:
Notepad Security
So you've been able to get a foothold onto the network, but are having difficulty accessing the root accounts. With a bit of social engineering you've learned they're locked down using randomly generated passwords oy vey! So hashcracking will take forever and people probably won't know them, however there's a chink in the armour, turns out they use a keepass database stored centrally to generate and store these passwords and you reckon you can reach it. Even better it turns out to access this database they keep a password stored in notepad! Using wireshark you intercept this file being passed to a new member of the admin team, you're pretty sure the info you need is hidden in there somewhere and they seem to have taken some measures to obscure it, so have at it and drag that password out!
If you've not seen it before feel free to have a go before reading on, see how far you get on your own. By now this puzzle is over 10 months old so I don't think there's any harm in spoiling it, but I'll still hide the answers so you can't discover them by accident. One thing I will say though is I found one extra clue was needed to help people find the solution so I'll include that here, though it is still theoretically possible without it the clue just helps guide you to get an initial footing.
Clue
the compressed file is a .txz
So how does that help? Well, for that we'll have to dig in a little bit, so lets get started. Now the first thing to note is that if Wireshark is doing its job properly and gathered the full transfer it would be trivial to pull the file out of the packet capture, but that doesn't seem to be the case here. What we've ended up with is not a PcapNg at all but some sort of binary stream as can be seen by the .bin extension, and that means we're likely going to have to pull the file out ourselves, we should expect irrelevant data both before and after the file.
If you aren't too familiar with working with files on a binary level you may not be aware, but the way filesystems work and can tell different files apart is that in the header data the first thing you will find is what is known as a magic number or file signature. These numbers are well documented, so where do you look for them? You can literally ask Google, I find the best place is usually Wikipedia. Now if you find the one for a .txt file such as Notepad uses, you'll see it has a few.. uh-oh! You can search through the binary file for these but I guarantee if you turn up anything its a red herring, I deliberately set it up this way to be confusing and slow people down, so lets back up a little and think our way around this.
We know from the description somewhere in here is a text file such as Notepad uses, but it also mentioned they'd done something to obscure it, so its a fair bet its not just a .txt file surrounded by garbage. Now the original intent here was for you to search through looking for different file types, but there are quite frankly a lot, specialized software could probably find it but this challenge is for newbies so I soon added a clue to fix that. So this is where the clue is important, it lists the extension type and says something about it being compressed. If you have a Google you'll find that its a file that is tar archived and compressed using LZMA but I wouldn't worry about all that, just think of it like a zip or a rar file.
So scroll down your file signature list to find the one you need and you should see FD 37 7A 58 5A 00 if you're having difficulty just search for 'tar'. Okay so how do we search a binary file? Well its possible on Windows but usually easier on Linux, I'm going to assume that's what you're using since you're learning about security, if not, use your Google Fu and find some good tools for your OS. You can use hexdump for this but personally I find xxd much easier to use, here's the command and output I got:
~> xxd binary.bin | grep "fd37" 00001840: 3edd 8e90 3276 65b9 fd37 7a58 5a00 0004 >...2ve..7zXZ... 00004cc0: 79ad fd37 f3df 7570 833a 9627 af87 efa8 y..7..up.:.'....
As you can see I've used grep to search through the output, its an immensely powerful tool and you really should learn how to use it if you don't already know. There we go you can see we do have a full file signature on the line marked 1840 which is hexadecimal so a quick conversion to decimal says that is line 6208, add in the 8 byte pairs to get to the signature itself and the file starts at 6216. We can check this with a quick command using head to only grab the first few lines:
~> xxd -seek 6216 binary.bin | head
00001848: fd37 7a58 5a00 0004 e6d6 b446 0200 2101 .7zXZ......F..!.
00001858: 1600 0000 742f e5a3 e18f ff56 ba5d 0038 ....t/.....V.].8
00001868: 184a e003 09cf f7ff 13e8 2c05 8aab 7312 .J........,...s.
00001878: 77d0 96b7 76c0 a5b7 f1e9 6b9c d868 118d w...v.....k..h..
00001888: ae64 2dd2 c396 8e5c e316 731a 7d38 8221 .d-....\..s.}8.!
00001898: d5c9 dd35 e43f 954a 4c33 af9d 5709 9e15 ...5.?.JL3..W...
000018a8: 4211 0369 ec89 4b96 7b35 fb16 56a2 532c B..i..K.{5..V.S,
000018b8: 7d6e 113b a475 5e8d a048 05f5 c0d2 236d }n.;.u^..H....#m
000018c8: c5ee ca77 d012 c4cb 0a21 34dd 32e7 a557 ...w.....!4.2..W
000018d8: 88da 9de5 915f fa14 6b16 b7bb 346a 6a0a ....._..k...4jj.
Alright now we're getting somewhere, the next step is to copy the binary from that point on into a new file, we can do that with dd. The flags I've given simply set the input file, output file, block size, what byte to skip to, and to display the process as it does it which is really just a quality of life upgrade for long copies. You could also set count to the amount of bytes to write, but we don't know how big the file is. You could probably with some effort find the end of the file too and cut off the excess but its not all that necessary as the file header will tell the file how big it is and due to how they're built finding the end can be quite tricky with tar compressed files.
~> dd if=binary.bin of=binary.txz bs=1 skip=6216 status=progress 37023+0 records in 37023+0 records out 37023 bytes (37 kB, 36 KiB) copied, 0.076196 s, 486 kB/s
So now you should be able to find the new file in your filesystem, it should be in the same folder the binary file was in. You can do the next bit through the command line or the gui if you like, I went with the gui because it handled it a bit better. Essentially you just extract the compressed file, I opened it with Ark so I could extract only the one file I needed and sure enough there was 'passwords.txt'. Upon opening it though you realise your work isn't yet done, and you start to see what the prompt meant by they'd obscured it... is that?... lorem ipsum?
Okay so the file has been filled with huge amounts of completely irrelevant data, clearly they have some means of stripping out the password and think this is a good security measure. There's so many words in fact it causes KWrite to hit the Line Length Limit!
Anyway this sort of nonsense is trivial to overcome, a simple find can do it, and most text processors have some sort of feature built in for it. The hardest part is figuring out what to search for, but remember, we're looking for a flag, what does a flag have that regular text does not? Curly braces {}. Now if this feels like a bit of a cheat remember even in a real world scenario the file would have something identifiable to extract the password, and if software can find it, a find function almost certainly can. This means that such a method of obscuring data is basically pointless, but believe it or not people do still do this in the real world, so you may actually encounter this in practice, though I sincerely hope not. Anyway once you've run the find you should have the flag, check against the one below to see if you succeeded.
Answer
BitRot{tNWkfz9RfTlaJHEzFw9U-4-0x00000000-U70VMF9xDQJfN9-YIoJbE}