6 minutes ago, Squid said:

 

 

Liked the first one better.

 

 

Edited August 7, 20178 yr by wgstarks

13 minutes ago, kjoconis said:

Hey Squid,

 

Bait files enabled, Bait files running, shows 117160 files being monitored.

 

 

config/plugins/ransomware.bait/filelist has the list of every file monitored.  If its listed as being monitored (and you say its show 117,000), then it should be in the appropriate folders.

 

You'd have to confirm via the command prompt though. eg:

ls /mnt/user/Movies

Edited August 7, 20178 yr by Squid

So, I never had something trigger Squidbait until tonight.

 

Got sick of waiting for SMB network access to come around when connecting from my Mac, so I enabled AFP for the specific share I wanted to access.

 

After briefly listing the share contents in Finder, Squidbait kicked off and shut down access:

 

Ransomware Protection: 08-09-2017 21:57

Possible Ransomware Attack Detected
Possible Attack On /mnt/user/TV Shows/SquidBait-DO_NOT_DELETE.docx

 

While I am not entirely ruling out that some mischief is going on, I find it more likely that MacOS and it's incessant need to disperse dot-files allover is at work.

 

Anyone have insights? 

 

Cheers,

 

T.

 

Edit: Just reset the permissions and tried accessing via AFP - triggered again. No issue when accessing over SMB apart from the horribly slow speed when listing large network shares.

Edited September 8, 20178 yr by t33j4y

I don't have access to a Mac, so not quite sure what to say.  RP is detecting a modification of the file in question, or a rename etc and triggering itself.  

 

Not sure if anyone else using AFP has ever seen the same behaviour

The .DS_Store files should be created on any type of volume or share (SMB or AFP, etc) so I don't think that's it. I wonder if it's getting some file system extended attribute added, though this should not change the actual hash of the file itself. Could you ssh in and inspect a bait file before mounting it on your Mac? Try running xattr /path/to/file and see what it returns and then run it again after mounting the share on your Mac.

Just reproduced the problem from my Macbook - so it happens when accessing from both my Mac mini and my MBP.

 

Will try to ssh in and check before and after as suggested :-)

 

Edited September 8, 20178 yr by t33j4y

I get "xattr: command not found". :-/

 

Can you do this.  Fix the RW permissions (ie: disable AFP), then from a console

inotifywait --fromfile /boot/config/plugins/ransomware.bait/filelist -e move,delete,delete_self,move_self,close_write

 

Now re-enable AFP which you're saying gives the false trips.  The command should exit.  Post the output.

13 minutes ago, t33j4y said:

I get "xattr: command not found". :-/

 

 

Ah sorry brain fart, yeah that command wouldn't be available on your server. You'd need to run it locally on the SMB mount and compare to the AFP. I'd try Squid's steps first though. I can play around with this when I get home and see if I can repro too  

Disabled AFP on "offending" share.

SSh'ed in and ran the command you listed.

Re-enabled AFP

Accessed share (which triggered RP)

 

Output:

root@Tower:~# inotifywait --fromfile /boot/config/plugins/ransomware.bait/file>
Setting up watches.
Watches established.
/mnt/user/TV Shows/SquidBait-DO_NOT_DELETE.docx CLOSE_WRITE,CLOSE 
root@Tower:~# 
<st -e move,delete,delete_self,move_self,close_write      
Setting up watches.
Watches established.
/mnt/user/TV Shows/SquidBait-DO_NOT_DELETE.pdf CLOSE_WRITE,CLOSE 
root@Tower:~# 

 

 

Edited September 8, 20178 yr by t33j4y

ok.  Last step

 

Fix the problem again. Then

md5sum "/mnt/user/TV Shows/SquidBa*"

Trip it and run the command again

 

Post the results from both runs

 

Edited September 8, 20178 yr by Squid

4 minutes ago, Squid said:

 

The code box after "Fix the problem again. Then" is empty - can you please repost?

 

Thanks.

EDIT: You fixed the quote :-)

Edited September 8, 20178 yr by t33j4y

md5sum /mnt/user/TV\ Shows/SquidBa*

 

Output before tripping:

 

root@Tower:~# md5sum /mnt/user/TV\ Shows/SquidBa*
762e371d252f2575c7fe47af3d3d05f2  /mnt/user/TV Shows/SquidBait-DO_NOT_DELETE.docx
1812b82cd617c7cc6acab62809a1d531  /mnt/user/TV Shows/SquidBait-DO_NOT_DELETE.jpg
c5ec9350bdf66275683fc8a58b8aae85  /mnt/user/TV Shows/SquidBait-DO_NOT_DELETE.pdf
a01288d5973fc030b51db2f5a0cb9f03  /mnt/user/TV Shows/SquidBanking-DO_NOT_DELETE.xlsx

 

Output after tripping:

 

root@Tower:~# md5sum /mnt/user/TV\ Shows/SquidBa*
762e371d252f2575c7fe47af3d3d05f2  /mnt/user/TV Shows/SquidBait-DO_NOT_DELETE.docx
1812b82cd617c7cc6acab62809a1d531  /mnt/user/TV Shows/SquidBait-DO_NOT_DELETE.jpg
c5ec9350bdf66275683fc8a58b8aae85  /mnt/user/TV Shows/SquidBait-DO_NOT_DELETE.pdf
a01288d5973fc030b51db2f5a0cb9f03  /mnt/user/TV Shows/SquidBanking-DO_NOT_DELETE.xlsx

 

Just now, t33j4y said:

Output before tripping:

 

root@Tower:~# md5sum /mnt/user/TV\ Shows/SquidBa*
762e371d252f2575c7fe47af3d3d05f2  /mnt/user/TV Shows/SquidBait-DO_NOT_DELETE.docx
1812b82cd617c7cc6acab62809a1d531  /mnt/user/TV Shows/SquidBait-DO_NOT_DELETE.jpg
c5ec9350bdf66275683fc8a58b8aae85  /mnt/user/TV Shows/SquidBait-DO_NOT_DELETE.pdf
a01288d5973fc030b51db2f5a0cb9f03  /mnt/user/TV Shows/SquidBanking-DO_NOT_DELETE.xlsx

 

Output after tripping:

 

root@Tower:~# md5sum /mnt/user/TV\ Shows/SquidBa*
762e371d252f2575c7fe47af3d3d05f2  /mnt/user/TV Shows/SquidBait-DO_NOT_DELETE.docx
1812b82cd617c7cc6acab62809a1d531  /mnt/user/TV Shows/SquidBait-DO_NOT_DELETE.jpg
c5ec9350bdf66275683fc8a58b8aae85  /mnt/user/TV Shows/SquidBait-DO_NOT_DELETE.pdf
a01288d5973fc030b51db2f5a0cb9f03  /mnt/user/TV Shows/SquidBanking-DO_NOT_DELETE.xlsx

 

Not what I was hoping for....  md5's match before trip and after trip.  Assuming that you enabled AFP on TV Shows, I'll have to get back to you in a couple of days when I can figure out why the code is failing on a close_write when the md5 matches...  

I just ran the steps again to be sure - it outputs matching md5 :-/

 

Will await your feedback in a couple of days :-)

 

Thank you for your support!

Edited September 8, 20178 yr by t33j4y

Hi Squid. Have you had a chance to dig deeper into this? :-)

 

Thanks.

Actually forgot all about it.  I'll start on it tonight

Not quite sure.  It all works for me.  I can emulate your problem by simply loading one of the xlsx files into excel and then closing it without making any changes.

Sep 17 09:03:57 Server_A root: ransomware protection:Event on /mnt/user/Intimate/SquidBait-DO_NOT_DELETE.docx, but MD5 matches.  Checking again in 1 second
Sep 17 09:03:58 Server_A root: ransomware protection:Event on /mnt/user/Intimate/SquidBait-DO_NOT_DELETE.docx, but MD5 matches.  Remonitoring
Sep 17 09:03:58 Server_A root[21619]: Setting up watches.
Sep 17 09:03:58 Server_A root[21619]: Watches established.
Sep 17 09:04:08 Server_A root: ransomware protection:Event on /mnt/user/Intimate/SquidBanking-DO_NOT_DELETE.xlsx, but MD5 matches.  Checking again in 1 second
Sep 17 09:04:09 Server_A root: ransomware protection:Event on /mnt/user/Intimate/SquidBanking-DO_NOT_DELETE.xlsx, but MD5 matches.  Remonitoring
Sep 17 09:04:09 Server_A root[21740]: Setting up watches.
Sep 17 09:04:09 Server_A root[21740]: Watches established.

It saw that a CLOSE_REWRITE happened, the md5's matched, checked again it still matched, so ignored the event and started the monitoring back up again, then excel triggered it immediately again, and the same thing happened and then the file activity stayed stable, and the "attack" was ignored.

Edited September 17, 20178 yr by Squid

Maybe the file was still locked by the applications for a bit of time after the close_rewrite event and thus was unable to be check-summed? Sounds like a timing issue of playing roulette, making it very hard to reproduce reliably.

On 1/1/2017 at 8:07 AM, Squid said:

- Added ability to hide the bait files.  Pretty much requires you to stop the service, delete the bait files, then recreate.

- Due to a technical problem, the 4 base bait files in the root folder of each bait share cannot at this time be hidden.

 

Hide "dot" files has to be enabled in Settings - SMB settings for this to work.

When I first enabled your plugin, I did not realize I had that SMB setting disabled. I'm only running bait files at the root of all my shares. After disabling the plugin and deleting bait files, I stopped the array, turn on hide dot files in SMB settings and re-enabled the plugin. Those bait files are still visible and show hidden files in Windows explorer is not checked. When You say, " Due to a technical problem, the 4 base bait files in the root folder of each bait share cannot at this time be hidden." does that mean all shares or just the bait share created by the plugin? Thanks much!

9 minutes ago, geonerdist said:

When I first enabled your plugin, I did not realize I had that SMB setting disabled. I'm only running bait files at the root of all my shares. After disabling the plugin and deleting bait files, I stopped the array, turn on hide dot files in SMB settings and re-enabled the plugin. Those bait files are still visible and show hidden files in Windows explorer is not checked. When You say, " Due to a technical problem, the 4 base bait files in the root folder of each bait share cannot at this time be hidden." does that mean all shares or just the bait share created by the plugin? Thanks much!

I don't recall the exact technical problem, but it is only the baitshares IIRC

4 minutes ago, Squid said:

I don't recall the exact technical problem, but it is only the baitshares IIRC

Hmm, any ideas why I still see the bait files when browsing my shares then? I did forget to say that I did select to hide the bait files when I setup the plugin too. I'm also on the current version of unRAID and the plugin. 

Edited September 29, 20178 yr by geonerdist

Not sure.  I'll get back to you

On 9/29/2017 at 11:25 AM, Squid said:

Not sure.  I'll get back to you

Any luck? If not is there any else I can get back to you with to help troubleshoot? I have been doing research and it doesn't sound like Windows hides files that begin with a period. It's a Unix/Linux thing...