The following example is a write-up of an example of payload execution that I performed for a University assignment. I have also created a TryHackMe room based upon this. I replicate a java application and the serialization process; ultimately being able to perform RCE on Windows 10.
This write-up is an example of the serialisation process of an application (in this instance, Java) can be maliciously intercepted, facilitating code execution via the form of launching an applicaton on Windows. I have replicated an application that you may find locally. In my case, this application seralizes Customer data - ready for traversal across the network, which I have simulated across two VM’s. Outputting it to a file named
Note, this isn’t a new exploit or a 0day of any kind. Deserialisation atacks via CommonsCollections isn’t a brand new topic - albeit - still very prevalent today.
2. The Environment
Our data to be serialised across the simulated network:
When inspected, it’s hex encoded - aka serialised:
This is a seralised abstraction of the data that we have just saved (cust.name and cust.email). Notice the small quantity of data here for later. If I was to de-serialise this data, we would see the Object containing the data being reconstructed from this byte stream.
This is how the data should derserialise!
3. Performing Remote Code Execution
Let’s generate our first payload using Ysoserial!
Here we can view the hex-encoded payload. Notice how it is considerably larger then our original data in this case.
This is our payload… Now, when returning to my application that is acting as the de-serialisation in the process, instead of submitting a file to a vulnerable URL (Like that of a JBoss Server), this app simply takes seralised data stored within a file - exploit.ser which is where we have saved our payload too.