fgrep XDVR (cctv/dvr)

[glaslos]

@gento I see a bunch of those lately:
fgrep XDVR /mnt/mtd/dep2.sh\x00
after that there is no additional step. I assume they expect a specific response payload.

[gento]

Yeah I saw it too. With some Google search, I believe it is waiting for the specific responses of the content in dep2.sh. I am trying to the real content of dep2.sh, no luck as for now

Also, I saw there are always same credentials prior these fgrep attempts.

I will try to dig further

[wintermanc3r]

I did some research on this and found: https://github.com/k1p0d/h264_dvr_rce/blob/master/h264-dvr-rce.py and the article had some references to the dep2.sh file

I tried using the dep2.sh file from: http://qsee.custhelp.com/app/answers/detail/a_id/1275/~/qt446%3A-firmware-version-3.2.0-(latest)

And get no responses. That fgrep on the dep2.sh from the linked firmware will return cd /mnt/mtd && ./XDVRStart.hisi ./td3520 &

[glaslos]

Ah, nice catch @wintermanc3r . Did you add that string to Glutton to see if we see further steps in that attack scenario?

[wintermanc3r]

I've actually been using my own honeypot (this is literally the only link on Google I could find that applies to this traffic!), but I've tried
cd /mnt/mtd && ./XDVRStart.hisi ./td3520 & and
cd /mnt/mtd && ./XDVRStart.hisi ./td3520a &

without any success. This is definitely the right track so I'm going to poke around some more and see if I can find any other versions of the firmware, and will let you know if I find the desired response. Between this and the bot I've ran into running crontab, passwd, reboot (that actually tried repeatedly to shut my honeypot down with forkbombs and /dev/urandom redirection) things get more curious every day...

[gento]

Nice @wintermanc3r . I am adding to mine and testing it now. Will see what we can get later. Cheers!

[glaslos]

@gento any success?

[gento]

@glaslos I tried the same way as @wintermanc3r

cd /mnt/mtd && ./XDVRStart.hisi ./td3520 &

No luck for me as the moment