Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enrich DNS indicators #36

Closed
krmaxwell opened this issue Aug 3, 2014 · 6 comments · Fixed by #112
Closed

Enrich DNS indicators #36

krmaxwell opened this issue Aug 3, 2014 · 6 comments · Fixed by #112
Assignees

Comments

@krmaxwell
Copy link
Member

LeaveNoIndicatorBehind

@krmaxwell krmaxwell added this to the v1.1 milestone Aug 3, 2014
krmaxwell pushed a commit that referenced this issue Aug 4, 2014
@alexcpsec alexcpsec modified the milestones: v0.1.1 Ascended Capybara, v1.1 Sep 16, 2014
@krmaxwell krmaxwell self-assigned this Sep 26, 2014
@alexcpsec alexcpsec assigned alexcpsec and unassigned krmaxwell Sep 26, 2014
@krmaxwell
Copy link
Member Author

So, um. What do we want to do on this one?

@alexcpsec
Copy link
Member

So here is the original spec of what I wanted to do for the tiq-test enrichment format.

We would get something like this from the raw data:

"entity","type","direction","source","notes","date"
"bgr.runk.pl","FQDN","outbound","mtc_malwaredns","Malware","2014-06-01"

And turn it into (getting some random IPs and enrichments to illustrate):

"entity","type","direction","source","notes","date","asnumber","asname","country","host","rhost"
"31.210.109.42","IPv4","outbound","mtc_malwaredns","Malware","2014-06-01","9318","Hanaro Telecom Inc.","XX","bgr.runk.pl","whatever.rdomain.com"
"5.63.155.203","IPv4","outbound","mtc_malwaredns","Malware","2014-06-01","2343","ASN for what?","XX","bgr.runk.pl","whatever.rdomain2.com"

So in this "enrichment type", we are transforming the FQDN entries into enriched IPv4 entries doing the following:

  1. We run the FQDN entity through the Passive DNS database (an A query), limiting the IP response to the date of the indicator. So algorithmically we only return IPs where (firstseen <= $date 23:59:59) && (lastseen >= $date 00:00:00)

  2. These IPs are used to create new IPv4 entries where source, notes and date are the same as the original FQDN entry, and the host column is populated by the original FQDN entity.

  3. These new IPv4 entries are enriched using the process we already defined for enrich_ip to add asnumber, asname, country and rhost

Of course this is all moot if there is no DNSDB key. In that case, all FQDN entries should be dropped on the enrichment.

@krmaxwell
Copy link
Member Author

What we currently lack is (3), I believe. We already do (1) and most of (2), though it needs a bit of extension to be complete.

@alexcpsec
Copy link
Member

Let me know if I can help.

@krmaxwell
Copy link
Member Author

In the final, enriched data, does the FQDN still have its own entry, or are we just using the IPv4 entry? In other words, does the original FQDN IOC map to 1️⃣ or 2️⃣ enriched IOCs? I think it should be two, myself.

@krmaxwell
Copy link
Member Author

nvm I figured out where everything goes. 😊

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants