0/18 byte files in replay folder

[PersonaN0nGrata]

Is there a way to stop it from making replay files and the player tabs on every scan? It makes it rather difficult to sort through.

[Res260]

We had a feature where empty files were deleted, has there been a regression? 🤔

[PersonaN0nGrata]

Oh shit, maybe i just need to update, cool.
I´ll try that out

[Res260]

Report back if it works, if it doesnt tell us if the files are actually empty, or very small!

[PersonaN0nGrata]

so i did a git pull and its is still making 0b and 18b files =/

[Res260]

I think that 18 bytes files are not simple SYN/SYNACK/ACK scans, but service scans, where the first RDP packet is sent to make sure the destination is an RDP server. Packet capture analysis could confirm that....

If it is the case, I'm not sure that we want to delete those files 🤔

@obilodeau thoughts?

[obilodeau]

The 0 bytes ones should probably not be created but the 18 bytes ones might be interesting to dig deeper into what is going on.

We had a feature where empty files were deleted, has there been a regression? 🤔

Quickly grepping the codebase for unlink (python's delete api) and delete didn't lead to code handling those empty sessions... There is downloaded file deduplication (deleting on same hash) but not empty session deletion AFAICT.

So to me, this is two issues:

a. interactive player should open tab only when something was recorded (session logs should still be session logs, any non-zero log is interesting)
b. why do we have a lot of these 0 / 18 bytes sessions, that should be investigated

For either issue, I need to be able to reproduce the problem locally. @Norup123 can you provide a pcap or are you willing to wait until I get similar traffic in my honeypots?

[Res260]

I implemented that feature last year, but I think it got removed when @xshill did the big refactor:
bf27f03

[PersonaN0nGrata]

#158 trying to make a tcpdump for this. Havnt been able to capture the error in the other issue in the dump im currently making, but the error appeared right before i started, so hoping it will show again.

My /replay folder is FILLED with 0 or 18 byte files.
And still not a single attacker/bot has gone past the certificate error =/

[PersonaN0nGrata]

tcpdump.zip

Hope this is what you meant

[PersonaN0nGrata]

tcpdump2.zip
Currently getting these errors in my logs for every entry, and i cant get past the initial loading when i try to connect with rdp

[PersonaN0nGrata]

i may or may not have found my issue with the breaking. Could have been the windows machine, going on standby...

kay i actually think this was my issue.. unbelievable...

Still all the scans are showing up as 0 or 18b cluttering the replay folder, And also showing up on the player as "empty" closed tabs

These are the tabs from 1 night. Probably all emtpy. pretty rough to go through all the time

[alxbl]

As far as the player tabs are concerned, we could auto-close all tabs that last less than N seconds and all tabs that receive no data but are not disconnected after a long enough period of time.

The former would take care of scanners, while the latter would take care of "hung" connections that we have been seeing in some cases.

Alternatively, I'm pretty sure in either cases we never get far enough in the connection sequence to get video, so tabs that never made it to connection established after N seconds could be closed automatically. This approach would be cleaner.

[alxbl]

I suggest to track the tab creation issue in #142, and use this issue to track the small replay files.