(July 18, 2022, 08:58 AM)toatoat Wrote:

(July 17, 2022, 05:44 PM)yournamehere Wrote:

(July 15, 2022, 10:50 AM)yournamehere Wrote:

(July 15, 2022, 08:41 AM)toatoat Wrote:

(July 14, 2022, 03:16 PM)yournamehere Wrote: Head banging time again !

the pcap file gives good info about the attack chronology
we have 2 ssh sessions , but can't find a way decrypt them
I tried volatility against the memory dump as mentioned by @Unbolted5053 , but can't get it to work either
Gonna try to decrypt the metter session stream

A little nudge would be appreciated ;)

This is part is why the box is insane imo.
The goal of this part is to reconstruct the .zip archive that's been exfiltrated through meterpreter. There is some doc for this :
https://github.com/OJ/clr-meterpreter/blob/master/streams/2019-04-25-Part-2/tlv.md
https://www.rubydoc.info/github/rapid7/metasploit-framework/Rex/Post/Meterpreter/Packet
https://github.com/rapid7/metasploit-framework/pull/8625

The core_dump is only useful for the AES key.

Thanks a lot ! That's exactly what I'm at right now. I should get it very soon

so... I got the zip file reconstructed and extracted. the zip file is corrupt and so is the png. the key is useless. Nothing obvious here :s
stegano maybe ? oh wow what a brainfuck !

The key is mandatory in order to reconstruct the zip correctly.
If your png/archive is corrupted after a binwalk, it means that you didn't extract the whole zip. Meterpreter packets are TLV packets (actually LTV packets) following one another. In order to extract the zip file, you got to parse the TLV packets by packet type too and append the payloads
When your zip file is correctly extracted from the conv, you should have 5 file, 2 of them are important for the rest (yes it's not over yet and the rest is also tricky)

I was talking about the key in the zip file. I did all the TLV parsing after AES. My zip file is corrupted because I think I screwed up an offset calculation at some stage ?  so I only have 4 files for now. But I think I got the 2 files you're talking about

(July 18, 2022, 02:41 PM)yournamehere Wrote:

(July 18, 2022, 08:58 AM)toatoat Wrote:

(July 17, 2022, 05:44 PM)yournamehere Wrote:

(July 15, 2022, 10:50 AM)yournamehere Wrote:

(July 15, 2022, 08:41 AM)toatoat Wrote: This is part is why the box is insane imo.
The goal of this part is to reconstruct the .zip archive that's been exfiltrated through meterpreter. There is some doc for this :
https://github.com/OJ/clr-meterpreter/blob/master/streams/2019-04-25-Part-2/tlv.md
https://www.rubydoc.info/github/rapid7/metasploit-framework/Rex/Post/Meterpreter/Packet
https://github.com/rapid7/metasploit-framework/pull/8625

The core_dump is only useful for the AES key.

Thanks a lot ! That's exactly what I'm at right now. I should get it very soon

so... I got the zip file reconstructed and extracted. the zip file is corrupt and so is the png. the key is useless. Nothing obvious here :s
stegano maybe ? oh wow what a brainfuck !

The key is mandatory in order to reconstruct the zip correctly.
If your png/archive is corrupted after a binwalk, it means that you didn't extract the whole zip. Meterpreter packets are TLV packets (actually LTV packets) following one another. In order to extract the zip file, you got to parse the TLV packets by packet type too and append the payloads
When your zip file is correctly extracted from the conv, you should have 5 file, 2 of them are important for the rest (yes it's not over yet and the rest is also tricky)

I was talking about the key in the zip file. I did all the TLV parsing after AES. My zip file is corrupted because I think I screwed up an offset calculation at some stage ?  so I only have 4 files for now. But I think I got the 2 files you're talking about

Yes, it happened to me as well at first. I made a script who decrypted then parsed TLV at the same time and it got real complicated to debug. I dunno if you did that but I ended up splitting the script in two script : one to decrypt then export to a pcap, one to parse TLV.
Did you find the packet_type of the ZIP TLV ?

(July 18, 2022, 02:55 PM)toatoat Wrote:

(July 18, 2022, 02:41 PM)yournamehere Wrote:

(July 18, 2022, 08:58 AM)toatoat Wrote:

(July 17, 2022, 05:44 PM)yournamehere Wrote:

(July 15, 2022, 10:50 AM)yournamehere Wrote: Thanks a lot ! That's exactly what I'm at right now. I should get it very soon

so... I got the zip file reconstructed and extracted. the zip file is corrupt and so is the png. the key is useless. Nothing obvious here :s
stegano maybe ? oh wow what a brainfuck !

The key is mandatory in order to reconstruct the zip correctly.
If your png/archive is corrupted after a binwalk, it means that you didn't extract the whole zip. Meterpreter packets are TLV packets (actually LTV packets) following one another. In order to extract the zip file, you got to parse the TLV packets by packet type too and append the payloads
When your zip file is correctly extracted from the conv, you should have 5 file, 2 of them are important for the rest (yes it's not over yet and the rest is also tricky)

I was talking about the key in the zip file. I did all the TLV parsing after AES. My zip file is corrupted because I think I screwed up an offset calculation at some stage ?  so I only have 4 files for now. But I think I got the 2 files you're talking about

Yes, it happened to me as well at first. I made a script who decrypted then parsed TLV at the same time and it got real complicated to debug. I dunno if you did that but I ended up splitting the script in two script : one to decrypt then export to a pcap, one to parse TLV.
Did you find the packet_type of the ZIP TLV ?

yup there are only 2 packets with this type, and can't be confused with other ones ;) got all 5 files now
BTW I used a script to parse all the first packets then did the zip recovery manually.
now I have to exploit those 2 files I think I can see something interesting and found some references

(May 16, 2022, 07:19 PM)Exa Wrote: I should have ignored the illegal characters error.

So the trick is to simply put an URL into PHPSESSID and copy the generated session_digest into url_digest.

Now I can access the chat application and I found the ZIP file.

guys any one here can help me at this part im stuck please help

(July 10, 2022, 02:36 PM)yournamehere Wrote: Finally escalated to Scryh . Oh wow I know why this box is called Response now!

Was fun though :P 

root part now. I think I got the logic already

Alright, you uplifted me.
Gotta try harder, with more knowledge! :D
https://www.digitalocean.com/community/tutorials/how-to-use-ldif-files-to-make-changes-to-an-openldap-system

Damn it! Alright people, question?! :D
No matter what I add or edit in ldap, I stuck with nslookup check.
Domain check will fail, and it will try to query customer server via DNS which is supposed to be my DNS.
.. oh shit! now I saw it but I was confused because whenever I add a server, and while working on it, it was removing my server back to default configuration.
So, looks like I am supposed to write an SH script that handles everything quickly before it turns back to default configuration.
Oki doki..

(July 18, 2022, 05:11 PM)yournamehere Wrote:

(July 18, 2022, 02:55 PM)toatoat Wrote:

(July 18, 2022, 02:41 PM)yournamehere Wrote:

(July 18, 2022, 08:58 AM)toatoat Wrote:

(July 17, 2022, 05:44 PM)yournamehere Wrote: so... I got the zip file reconstructed and extracted. the zip file is corrupt and so is the png. the key is useless. Nothing obvious here :s
stegano maybe ? oh wow what a brainfuck !

The key is mandatory in order to reconstruct the zip correctly.
If your png/archive is corrupted after a binwalk, it means that you didn't extract the whole zip. Meterpreter packets are TLV packets (actually LTV packets) following one another. In order to extract the zip file, you got to parse the TLV packets by packet type too and append the payloads
When your zip file is correctly extracted from the conv, you should have 5 file, 2 of them are important for the rest (yes it's not over yet and the rest is also tricky)

I was talking about the key in the zip file. I did all the TLV parsing after AES. My zip file is corrupted because I think I screwed up an offset calculation at some stage ?  so I only have 4 files for now. But I think I got the 2 files you're talking about

Yes, it happened to me as well at first. I made a script who decrypted then parsed TLV at the same time and it got real complicated to debug. I dunno if you did that but I ended up splitting the script in two script : one to decrypt then export to a pcap, one to parse TLV.
Did you find the packet_type of the ZIP TLV ?

yup there are only 2 packets with this type, and can't be confused with other ones ;) got all 5 files now
BTW I used a script to parse all the first packets then did the zip recovery manually.
now I have to exploit those 2 files I think I can see something interesting and found some references

Im on scry -> root.
I have the incident files.
Im trying to decrypt packets.

How did you get the AES keys? Do you have to reverse engineer the coredump binary?

(September 18, 2022, 07:13 PM)pleasehelpme Wrote:

(July 18, 2022, 05:11 PM)yournamehere Wrote:

(July 18, 2022, 02:55 PM)toatoat Wrote:

(July 18, 2022, 02:41 PM)yournamehere Wrote:

(July 18, 2022, 08:58 AM)toatoat Wrote: The key is mandatory in order to reconstruct the zip correctly.
If your png/archive is corrupted after a binwalk, it means that you didn't extract the whole zip. Meterpreter packets are TLV packets (actually LTV packets) following one another. In order to extract the zip file, you got to parse the TLV packets by packet type too and append the payloads
When your zip file is correctly extracted from the conv, you should have 5 file, 2 of them are important for the rest (yes it's not over yet and the rest is also tricky)

I was talking about the key in the zip file. I did all the TLV parsing after AES. My zip file is corrupted because I think I screwed up an offset calculation at some stage ?  so I only have 4 files for now. But I think I got the 2 files you're talking about

Yes, it happened to me as well at first. I made a script who decrypted then parsed TLV at the same time and it got real complicated to debug. I dunno if you did that but I ended up splitting the script in two script : one to decrypt then export to a pcap, one to parse TLV.
Did you find the packet_type of the ZIP TLV ?

yup there are only 2 packets with this type, and can't be confused with other ones ;) got all 5 files now
BTW I used a script to parse all the first packets then did the zip recovery manually.
now I have to exploit those 2 files I think I can see something interesting and found some references

Im on scry -> root.
I have the incident files.
Im trying to decrypt packets.

How did you get the AES keys? Do you have to reverse engineer the coredump binary?

you can get the binary executable from pcap and inspect the coredump in gdb: gdb binary coredump.

• reverse the executable, search the api, and find the source code for the library used.
• find in source code where the AES key is stored, and the allocation sizes of each relative structure.
• you can inspect the stack area, dump upto stack frame of main, and collect heap pointers (addresses significantly differs from function pointers)
• checking the chunck size of each heap pointer, find one that matches the top control structure. from there you can follow the structures and find the AES key storage.

(September 19, 2022, 03:25 AM)technic Wrote:

(September 18, 2022, 07:13 PM)pleasehelpme Wrote:

(July 18, 2022, 05:11 PM)yournamehere Wrote:

(July 18, 2022, 02:55 PM)toatoat Wrote:

(July 18, 2022, 02:41 PM)yournamehere Wrote: I was talking about the key in the zip file. I did all the TLV parsing after AES. My zip file is corrupted because I think I screwed up an offset calculation at some stage ?  so I only have 4 files for now. But I think I got the 2 files you're talking about

Yes, it happened to me as well at first. I made a script who decrypted then parsed TLV at the same time and it got real complicated to debug. I dunno if you did that but I ended up splitting the script in two script : one to decrypt then export to a pcap, one to parse TLV.
Did you find the packet_type of the ZIP TLV ?

yup there are only 2 packets with this type, and can't be confused with other ones ;) got all 5 files now
BTW I used a script to parse all the first packets then did the zip recovery manually.
now I have to exploit those 2 files I think I can see something interesting and found some references

Im on scry -> root.
I have the incident files.
Im trying to decrypt packets.

How did you get the AES keys? Do you have to reverse engineer the coredump binary?

you can get the binary executable from pcap and inspect the coredump in gdb: gdb binary coredump.

• reverse the executable, search the api, and find the source code for the library used.
• find in source code where the AES key is stored, and the allocation sizes of each relative structure.
• you can inspect the stack area, dump upto stack frame of main, and collect heap pointers (addresses significantly differs from function pointers)
• checking the chunck size of each heap pointer, find one that matches the top control structure. from there you can follow the structures and find the AES key storage. 

I read all the docs about TLV packets that I was able to find and yet stuck on this part.
https://github.com/OJ/clr-meterpreter/blob/master/streams/2019-04-25-Part-2/tlv.md

We need to de XOR  all the packets first and then we need to extract an encryption key right?  How to find and extract this encryption key for the packets? and how do we know that packets Non-encrypted or encrypted?

and there's more.. some packets have 00 04 00 01  as a XOR key, but some 00 00 00 001:

0000  00 04 00 01 00 06 08 00 27 9d 84 9e 02 74 08 00
0010  45 00 00 3c 2d 8b 40 00 40 06 de ce 0a 0a 0d 25
0020  0a 0a 0d 2a a2 ba 11 5c c9 ef 8a d5 00 00 00 00
0030  a0 02 fa f0 2e 91 00 00 02 04 05 b4 04 02 08 0a
0040  5e 55 23 f4 00 00 00 00 01 03 03 07

another:
0000  00 00 00 01 00 06 08 00 27 2a be 42 36 4d 08 00
0010  45 00 00 3c 00 00 40 00 40 06 0c 5a 0a 0a 0d 2a
0020  0a 0a 0d 25 11 5c a2 ba d7 96 03 14 c9 ef 8a d6
0030  a0 12 fe 88 da d6 00 00 02 04 05 b4 04 02 08 0a
0040  a2 ec 37 70 5e 55 23 f4 01 03 03 07

don't really get it.. is it suppose to change?
I have read some nice blog post https://www.bussink.net/meterpreter-reverse_http-how-does-it-communicate-between-device-and-the-msf/
where he's just de XOR-ing packets to at least see a key. but i don't see such a thing...

(September 21, 2022, 12:12 AM)onl1_f4ns Wrote:

(September 19, 2022, 03:25 AM)technic Wrote:

(September 18, 2022, 07:13 PM)pleasehelpme Wrote:

(July 18, 2022, 05:11 PM)yournamehere Wrote:

(July 18, 2022, 02:55 PM)toatoat Wrote: Yes, it happened to me as well at first. I made a script who decrypted then parsed TLV at the same time and it got real complicated to debug. I dunno if you did that but I ended up splitting the script in two script : one to decrypt then export to a pcap, one to parse TLV.
Did you find the packet_type of the ZIP TLV ?

yup there are only 2 packets with this type, and can't be confused with other ones ;) got all 5 files now
BTW I used a script to parse all the first packets then did the zip recovery manually.
now I have to exploit those 2 files I think I can see something interesting and found some references

Im on scry -> root.
I have the incident files.
Im trying to decrypt packets.

How did you get the AES keys? Do you have to reverse engineer the coredump binary?

you can get the binary executable from pcap and inspect the coredump in gdb: gdb binary coredump.

• reverse the executable, search the api, and find the source code for the library used.
• find in source code where the AES key is stored, and the allocation sizes of each relative structure.
• you can inspect the stack area, dump upto stack frame of main, and collect heap pointers (addresses significantly differs from function pointers)
• checking the chunck size of each heap pointer, find one that matches the top control structure. from there you can follow the structures and find the AES key storage. 

I read all the docs about TLV packets that I was able to find and yet stuck on this part.
https://github.com/OJ/clr-meterpreter/blob/master/streams/2019-04-25-Part-2/tlv.md

We need to de XOR  all the packets first and then we need to extract an encryption key right?  How to find and extract this encryption key for the packets? and how do we know that packets Non-encrypted or encrypted?

and there's more.. some packets have 00 04 00 01  as a XOR key, but some 00 00 00 001:

0000  00 04 00 01 00 06 08 00 27 9d 84 9e 02 74 08 00
0010  45 00 00 3c 2d 8b 40 00 40 06 de ce 0a 0a 0d 25
0020  0a 0a 0d 2a a2 ba 11 5c c9 ef 8a d5 00 00 00 00
0030  a0 02 fa f0 2e 91 00 00 02 04 05 b4 04 02 08 0a
0040  5e 55 23 f4 00 00 00 00 01 03 03 07

another:
0000  00 00 00 01 00 06 08 00 27 2a be 42 36 4d 08 00
0010  45 00 00 3c 00 00 40 00 40 06 0c 5a 0a 0a 0d 2a
0020  0a 0a 0d 25 11 5c a2 ba d7 96 03 14 c9 ef 8a d6
0030  a0 12 fe 88 da d6 00 00 02 04 05 b4 04 02 08 0a
0040  a2 ec 37 70 5e 55 23 f4 01 03 03 07


don't really get it.. is it suppose to change?
I have read some nice blog post https://www.bussink.net/meterpreter-reverse_http-how-does-it-communicate-between-device-and-the-msf/
where he's just de XOR-ing packets to at least see a key. but i don't see such a thing...

For XOR-key, it is changing for each packet.
Some corrections to above link on tlv packet: 

    4 bytes         16 bytes           4 bytes       4 bytes   4 bytes
[    XOR KEY   ][ SESSION GUID ][ ENCRYPTION FLAG ][ length ][  type  ][ data ]
                [               THIS IS XORED                                 ]

the length field counts from length field onwards (length + type + data)
ENCRYPTION FLAG = 1 indicates data part is AES encrypted (16-bytes IV + encrypted data)
ENCRYPTION FLAG = 0 indicates data part is not encrypted (a series of TLVs)
noting a tlv packet may span across several TCP packets.

For AES encrypt key you need to extract from coredump (follow the previous post)