[Bro] Intel::FILE_NAME and SMB_files behavior questions

[James Gordon]

Hey Seth and Mark,

First off, thanks for the info! Mark, I'll work on flushing out that code -
looks like exactly what I need to alert on those types of filenames (if
there turns out to be value there :) )

Seth - in my testing on this, I was transferring a text document titled
'ntds.dit' over an SMB connection that Bro was monitoring. I think my
confusion on this is over what the SMB analyzer chooses to send into
files.log. I would expect to see the filename of a file that was written
over that connection, where in this case I had files that were opened (as
you mentioned, probably just by the client caching timestamps), but not the
file that was actually sent over that connection.

In my original email, I'd mentioned a red team 'adversary' pulled the
ntds.dit file off a domain controller and sent it to his system over an SMB
connection. For this connection, I have an smb_files log entry AND a
files.log entry that log a filename of: temp//ntds.dit being transferred.
When I created a test text document named 'ntds.dit' and sent it to a
remote fileshare, bro recorded the correct name in smb_files.log, but
nothing about that file in files.log!

I'd like to rephrase my questions a little:
1.When does a filename seen over SMB appear in files.log?

As far as flushing out some of the noise in smb_files.log - would it be
possible to only log FILE_OPEN's where the file has a 'time accessed'
timestamp that falls in the duration of the connection? This might not be
foolproof, but could cut down on file_open noise substantially. Just
brainstorming on this - but it seems like that would eliminate a lot of the
noise where the smb client "opens" a file but really just grabs that file's
timestamps or other metadata.




On Thu, Apr 5, 2018 at 6:16 AM, Seth Hall <seth at corelight.com> wrote:

>
> On 31 Mar 2018, at 18:14, James Gordon wrote:
>
> I have a few questions on behavioral issues with the intel framework and
>> SMB / SMB file logging:
>>
>> 1. I’m not sure if this is expected behavior or not, but it doesn’t look
>> like filenames parsed in smb_files.log are properly being logged in
>> files.log.
>>
>
> I checked in our autogenerated documentation and I'm now noticing a
> glaring lack of documentation about *what* that log represents. :(
>
> That log is meant to represent that an action against a file was seen.
> Considering that since SMB is a file system protocol you will see a lot of
> actions that aren't necessarily file transfers.  Most of what I've
> typically seen in smb_files.log is files being opened.  This seems be a
> very common action in SMB, I don't know all of the reasons that an
> application might open a file but not read nor write to it but it's
> definitely seen a lot.  I think that it could be a way for the client to
> get a timestamp for a remote file or other metadata.  Other actions that
> fits into that log are file renames and deletes.  File renames are
> represented through the "name" and "prev_name" fields.  Deletes just give
> the name of the file before it was deleted.
>
> The important field to look at is the "action" field since that's where
> the log tells you what the client was actually doing.  Here are all of the
> potential actions that you will typically see there...
>                 FILE_OPEN,
>                 FILE_RENAME,
>                 FILE_DELETE,
>
> If you wanted, you could add FILE_CLOSE as action that you want logged if
> you add this to your local.bro (I chose to leave this out by default since
> it didn't seem to provide much extra context, but had a great increase in
> log size)...
>
> redef SMB::logged_file_actions += { SMB::FILE_CLOSE };
>
> You could also have it include FILE_WRITE and FILE_READ, but those are
> really not great to include and lead to a massive increase in log size but
> I felt like transfers were better represented through the files.log
> anyway.  Generally if data is seen as being transferred that will be
> represented in files.log since that's the aggregation point for all "files"
> seen by Bro.  smb_files.log can be really helpful if you need to know when
> someone is poking around at files even if they aren't transferring them and
> there is a lot of information there that can be useful forensically (MAC
> times being the big one in my mind).
>
> If you have thoughts on other SMB logs that you'd like to see or if you
> have thoughts on extensions to the smb_files.log I'd love to hear them!
> There is definitely no right or wrong answer to what should be in those
> logs or even what logs should exist.
>
>   .Seth
>
> --
> Seth Hall * Corelight, Inc * www.corelight.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20180405/5b5a1df5/attachment.html