[Bro] Intel::FILE_NAME and SMB_files behavior questions

Tue Apr 3 02:15:40 PDT 2018

Hi James,

>> I don’t think the Intel framework supports wildcards – is there a way to alert
>> on files transferred that match a regex such as “Temp\\[a-zA-Z]{8}.tmp”,
>> or even: “Temp\\*.tmp”?

Use the ‘file_over_new_connection’ event.  You could get the file name from the SMB info in the ‘c : connection’ input argument to the event handler.  Here is some sample code:

event file_over_new_connection(f:fa_file, c:connection, is_orig:bool)
{
                if ( f?$source && f$source == "SMB" && c?$smb_state && c$smb_state?$current_file )
                {
                                local smb_path  = c$smb_state$current_file$path;
                                local smb_name = c$smb_state$current_file$name;

                                . . .Do regex pattern matching on smb_path and/or smb_name. . .
                                . . .Use Notice framework to raise an alert. . .
                }
}

Cheers,
Mark

From: bro-bounces at bro.org [mailto:bro-bounces at bro.org] On Behalf Of James Gordon
Sent: Saturday, March 31, 2018 6:14 PM
To: bro at bro-ids.org
Subject: [Bro] Intel::FILE_NAME and SMB_files behavior questions

Hey everyone,

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. We had a red team exercise recently where our red team was able to successfully retrieve the ntds.dit file off of one of our domain controllers. This transfer occurred over SMB, so I figured we could add ntds.dit to the Intel framework so that next time we don’t have to dig in logs to find out that our domain is owned – we’ll have a handy alert to tell us ** I did some testing with this though, and while I see ‘ntds.dit’ logged clearly in the name field in smb_files.log, I don’t have a corresponding entry in files.log for this file transfer, and therefore no Intel match. What makes this weirder is I have other irrelevant files from this connection logged in files.log, that I didn’t actually touch or move during this connection:

bro at SObro:/nsm/bro/logs/current$ cat /opt/bro/share/bro/intel/intel.dat | grep ntds.dit
ntds.dit                Intel::FILE_NAME            domain ownage - update your resume!              F

bro at SObro:/nsm/bro/logs/2018-03-31$ zcat smb_files.16\:00\:00-17\:00\:00.log.gz | bro-cut uid id.orig_h id.resp_h id.resp_p action name | grep ntds.dit
C35jBF1HlcrVNLiXW2 1.1.1.1    2.2.2.2  445     SMB::FILE_OPEN  share path\\and more\\more\\my testing directory\\ntds.dit
C35jBF1HlcrVNLiXW2 1.1.1.1    2.2.2.2  445     SMB::FILE_OPEN  share path\\and more\\more\\my testing directory \\ntds.dit <smb://ntds.dit> 
C35jBF1HlcrVNLiXW2 1.1.1.1    2.2.2.2  445     SMB::FILE_OPEN  share path\\and more\\more\\my testing directory \\ntds.dit <smb://ntds.dit> 
C35jBF1HlcrVNLiXW2 1.1.1.1    2.2.2.2  445     SMB::FILE_OPEN  share path\\and more\\more\\my testing directory \\ntds.dit <smb://ntds.dit> 
C35jBF1HlcrVNLiXW2 1.1.1.1    2.2.2.2  445     SMB::FILE_OPEN  ntds.dit
C35jBF1HlcrVNLiXW2 1.1.1.1    2.2.2.2  445     SMB::FILE_OPEN  ntds.dit
C35jBF1HlcrVNLiXW2 1.1.1.1    2.2.2.2  445     SMB::FILE_OPEN  ntds.dit
C35jBF1HlcrVNLiXW2 1.1.1.1    2.2.2.2  445     SMB::FILE_OPEN  ntds.dit

If I search for “ntds.dit” in files log, I get nothing. If I search for the connection UID in files.log, there are some files logged – but not the only file I actually transferred over this connection!

bro@ SObro:/nsm/bro/logs/2018-03-31$ zcat files.16\:00\:00-17\:00\:00.log.gz | bro-cut conn_uids tx_hosts rx_hosts source filename | grep C35jBF1HlcrVNLiXW2
C35jBF1HlcrVNLiXW2      1.1.1.1    2.2.2.2  SMB     desktop.ini
C35jBF1HlcrVNLiXW2      1.1.1.1    2.2.2.2  SMB     share path\\and more\\more\\not my testing directory!? \\desktop.ini <smb://desktop.ini> 
C35jBF1HlcrVNLiXW2      1.1.1.1    2.2.2.2  SMB     share path\\and more\\more\\my testing directory \\random <file://random>  file that lives at this path.exe
C35jBF1HlcrVNLiXW2      1.1.1.1    2.2.2.2  SMB     desktop.ini
C35jBF1HlcrVNLiXW2      1.1.1.1    2.2.2.2  SMB     favorites\\desktop.ini
C35jBF1HlcrVNLiXW2      1.1.1.1    2.2.2.2  SMB     Random excel file that lives in my testing directory.xls
C35jBF1HlcrVNLiXW2      1.1.1.1    2.2.2.2  SMB     random executable that lives in my testing directory.exe

Is there something wrong with my Bro instance? I feel like filenames from smb_files ‘name’ field should *all* be fed into files.log. I tested this with two different share paths and similar results – everything gets logged as I would expect in smb_files.log but this filename never shows up in files.log. How can I reliably alert on file names transferred over SMB?

2. As part of the above red team exercise, I found (what I suspect) are some instances of Meterpeter being transferred from popped hosts back to the adversary system over SMB. These were logged in “smb_files.log” with names like:  “Temp\\PBetVKZU.tmp” and “Temp\\FapcPatS.tmp”. I don’t think the Intel framework supports wildcards – is there a way to alert on files transferred that match a regex such as “Temp\\[a-zA-Z]{8}.tmp”, or even: “Temp\\*.tmp”?

3. Unrelated to the Intel framework - it seems like smb_files.log is super noisy. If I browse to a share drive, a massive amount of the contents of the share are enumerated in the smb_files log without taking any action (with the ‘action’ field indicating SMB::FILE_OPEN). This feels like expected behavior in SMB. Is there any way to ‘filter’ the log to only log files that are actually opened, written to, moved, deleted, or had any real operation occur against them? 

We’re running Bro 2.5.3 in Security Onion (Ubuntu 14.04). The intel framework is loaded and successfully fires on other indicators we have running.

Thanks!

James Gordon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20180403/6fba69b9/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6341 bytes
Desc: not available
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20180403/6fba69b9/attachment-0001.bin 