[01:52:05] <d4rkp1r4t3> nah hackers are lazy they would have it automated somehow. they just want the ransom paid and have no intentions of restoring the data. you mentioned nothing showing up in the mongo logs but perhaps you can get stats from the file system for last modified time to verify that something is indeed changing the data? also wouldnto verify that authentication is enabled
[07:46:30] <chovy> i have a 16 core server with 32gb ram
[09:23:37] <is_null> d4rkp1r4t3: agreed, this seems like a non targetting script that just runs on open mongos it find, and nothing more, according to their BTC account it's sufficiently profitable as-is
[09:25:03] <is_null> authentication was open, firewall was mounted (but we found out it doesn't work against docker exposed ports), we can't find if the container published the port, i can't find anything in the logs apart from the 22nd https://yourlabs.org/mongo.txt does anything seem odd/missing/tempered with to you ?
[15:53:00] <mahmoudajawad> I'm attempting to replace usage of update calls with aggregation pipelines. However I'm unable to do the following :
[15:55:00] <mahmoudajawad> Imagine a collection with one attribute as array of nested docs. With regular update call I could do {$set: {'attribute.2.sub_attribute': newValue}} to update only sub_attribute value of second array item of attribute.
[15:55:14] <mahmoudajawad> I'm unable to replicate the same behaviour with aggregation. Any hints?
[17:27:47] <mahmoudajawad> I got very close to what I want: https://pastebin.com/dc8i6Xwf
[17:28:38] <mahmoudajawad> My only concern is performance. Is there a better way to achieve the same? preferably by using single `$set` stage only.
[23:11:20] <chovy> heh, yeah docker exposing a lot of dbs w/o people knowing