Crowdstrike Additional Intel types

Hi All,
I was trying out the Crowdstrike bro additional Intel framework types http://blog.crowdstrike.com/maximizing-network-threat-intel-bro/ and very cool they are too.

But does anyone know if the Intel::USER_NAME could be extended to CIFS/SMB where the username is in the clear?

I have seen APT activity where service accounts that have been cracked and then used to attempt to authenticate to devices around the network. A simple CIFS honeypot might be used to attract an attacker to attempt authentication.

Or even the metasploit module:

msf exploit(phpmyadmin_config) > use auxiliary/server/capture/smb
msf auxiliary(smb) > set JOHNPWFILE /root/johnpwfile
JOHNPWFILE => /root/johnpwfile
msf auxiliary(smb) > exploit
[] Auxiliary module execution completed
msf auxiliary(smb) >
[
] Server started.
[*] SMB Captured - 2015-01-12 20:55:09 +0000
NTLMv2 Response Captured from 172.31.254.13:53729 - 172.31.254.13
USER:andy DOMAIN: OS:Mac OS X 10.10 LM:SMBFS 3.0.0
LMHASH:4d983d718a78a8692a5501f05c54f90a LM_CLIENT_CHALLENGE:cb67074c9d31d0bb
NTHASH:728a9e6db88b8b4ed3ff7832cfe8fc7e NT_CLIENT_CHALLENGE:0101000000000000009e550caa2ed001cb67074c9d31d0bb00000000000000000200000000000000

If it were possible to extend the scripts to examine the SMB username then the Intel framework would pick up on this activity just using a list of usernames that should not appear on the network.

Kind regards,
Andy
Andrew.Ratcliffe@NSWCSystems.co.uk
CISSP, GCIA, GCIH, GPEN, GWAPT, CSTA, CSTP, CWSA
Blog.InfoSecMatters.net

But does anyone know if the Intel::USER_NAME could be extended to CIFS/SMB where the username is in the clear?

Even better is that development on the Authentication framework has been picked up again and is making some progress. Personally I’d like to see it make it’s way into 2.4 so that we’d be able to have a generic, abstract implementation for authentication handling.

In the case of SMB, we’d just have a script that feeds SMB authentication information into the authentication framework in the cases we can grab it, and there will be another script that handles new authentications and feeds them into the intel framework. It should simplify and unify the work that Josh was aiming for with his scripts.

Unfortunately, the authentication framework is difficult enough that it’s taken quite a few years and input from at least 4 people to cover a good set of the potential use cases.

I have seen APT activity where service accounts that have been cracked and then used to attempt to authenticate to devices around the network. A simple CIFS honeypot might be used to attract an attacker to attempt authentication.

Agreed, although in this case, your whole network would be the honeypot. :slight_smile:

If it were possible to extend the scripts to examine the SMB username then the Intel framework would pick up on this activity just using a list of usernames that should not appear on the network.

Yep, that should be pretty easy to deal with once the rewritten SMB analyzer makes it into Bro along with the authentication framework which should make authentication handling much nicer for people writing scripts.

  .Seth

Hi Seth,
Thanks for the response. It sounds like there are few strands coming together soon that will make this, and much more, all possible; sounds good.

BTW: Enjoyed Floss Weekly 296!
Kind regards,

Andy
Andrew.Ratcliffe@NSWCSystems.co.uk
CISSP, GCIA, GCIH, GPEN, GWAPT, CSTA, CSTP
Blog.InfoSecMatters.net

Seth nailed it-- the Intel::USER_NAME fit a specific use case for me
(FTP authentication), so that's why I added it instead of waiting for
the Authentication framework. With that said, if the merge of the SMB
analyzer beats the merge of the Authentication framework, then we can
use a similar approach to check for SMB users via the Intel framework
using the username field in smb_cmd.log.

Very excited to see the Authentication framework when it's ready, that
should make all of this (and more) easier.

And thanks for that. I definitely think it makes sense to bash your way through any problems you’re running into rather than wait for a Bro release where we (at least attempt) to elegantly solve the problem. :slight_smile:

  .Seth