Investigating an alert, need help with additional meta

[Anonymous]

Here is my situation. I have a feed from a commercial threat intel provider that matches IPs and domains to threat actors.

I'm in the investigate module, investigating an alert on a dst.ip address that is alerting to a particular threat group, let's say APT1. The source of the event is from the firewall stating that the proxy server is connecting to the dst.ip

From local knowledge, I know the src.ip is the proxy server. the proxy server is generating logs to NetWitness but there is no connection between the src.ip and hostname of the proxy server. What I mean is that when I click on the alert for APT1, I see the firewall log entry stating that src.ip (proxy) connected to dst.ip (threat ioc) on port 443 but there is no corresponding proxy log as well.

What would be a way to join, connect, pivot (whatever the correct term) the proxy log data with the firewall data?

I don't think the proxy log is sending the src.ip, just the hostname or otherwise I'd assume I'd see that connection.

I'm going to assume the correct answer (correct me if I'm wrong) that I need to generate some common meta between the two to be able join the two together. If that's the case, would it be with a list in context hub, or a custom feed that has the ip and hostname of the proxy server or maybe some app rules to be able to get that connection.

Hope that makes sense, thanks for the help.

[JoshRandall]

You could do this several ways, a few of which you mention.

A feed will be the simplest, most efficient option and will likely be most usefull overall.

I'd also recommend that you do this not just for your proxy server, but all of your known/important/at-risk entities in your environment (servers, users, business units, facilities, etc.).

The more (accurate) context you have, the better.

[Anonymous]

Thanks for the reply.

So would I just built a CSV file with each line being 

X.X.X.X,<proxy_fqdn> 

Would I add additional data to the line and would I map the IP address to the index column when importing the feed.

The device.host is what the proxy logs are mapping it's hostname for.

[Anonymous]

Using a feed to tag sessions with extra meta for context is a great idea overall, but I don't think it answers your initial question of how to link the event from the firewall with the corresponding event from the proxy server. Using the feed mechanism as shown above will add a meta value of proxy.company.com to the meta key device.host to every event that includes the IP address of 192.168.1.1 - so in your example, the firewall event would include a bit of meta that essentially says "this event with ip.src 192.168.1.1 is traffic from the proxy server"

I'm assuming that you want to find the event from the proxy server that shows which downstream endpoint initiated the connection to the APT1 server so you can progress your investigation. You are right that in order to correlate these events together, there needs to be something common to both events. The proxy log probably includes the destination hostname (alisa.host) as part of event rather than the ip.dst, so you can't use ip.dst to link the events together. We'd need to look at the firewall event and the proxy event to determine if there are any fields that allow us to easily make the connection, or if extra logging can be turned on for each device to get the info we need.

[Anonymous]

You're right. I imported that feed and all it did was give some context highlighting for the context hub.

The logging on both the proxy and firewall are at the maximum, that it can go.

All the firewall logs show is src.ip > dst.ip > dst.port 

The proxy logs contain request url, user agent, user id, referrer, proxy hostname. 

I can't think of anything common to both linking them together other than the fact I know the src.ip matches the proxy hostname.

[Anonymous]

The joy of Logs!

So maybe we need info from another source. If you have DNS logs with the request and response (or even better NW Network capture of DNS queries) from the Proxy we could tie the ip.dst (in NW Network, the response to the DNS query would record the IP as alias.ip) to the hostname (alias.host). Then we get
Firewall = ip.src, ip.dst, tcp.dstport

DNS = alias.host, alias.ip (ip.dst)

Proxy = alias.host, ip.src

Also depends on the setting for the parsing of the Proxy logs as to whether the URL is parsed as a single meta value (url) or broken up into components of alias.host / directory / file

Another option with NW Network capturing the traffic from the proxy to the internet could be to use X-Forwarded-For header to get the IP address of the endpoint making the request through the proxy (orig.ip).