Add domain search capability to the API functions
I've been subscribing to the alerts for breaches related to our corporate domain, which is fantastic, but now that we have Splunk in house, I was hoping to connect directly to the API from a forwarder.
It's now live! Thank you all for supporting this idea, enjoy: https://www.troyhunt.com/welcome-to-the-new-have-i-been-pwned-domain-search-subscription-service/
Paul Venezio commented
I work for an MSP and would like the capability to search by our customer's domains (that we manage) and get the date of breach information along with the data already returned. I do not want to enumerate through a list of emails checking each one as I don't want to supply any 3rd party with that information if I don't have to. I just want to see what emails are out there and how old they are.
Vincent Castellano commented
I would be interested in a higher paid tier to support the engineering/infrastructure need to maintain ownership validation.
Roeland Jago Douma (rullzer) commented
In my opinion putting this behind an API key is indeed fine.
Having a process similar to ACME would make sure that users can only query it when doing they are still in possession of the domain.
Matt Holland commented
Adding my support for this feature. It would greatly reduce calls required to HIBP.
As a interim measure, could it be possible to simply structure the subscriber email to send similar JSON to the API responses. even better if we could subscribe for "regular confirmations of no findings" type emails
Rinck Sonnenberg commented
I would love to be able to do this via the (paid) API! Monitoring all our individual users/accounts is also possible, but being able to simply subscribe to all email addresses for a domain is a lot easier. I guess the API would then also need to support the possibility to verify ownership (preferably via DNS for my use case, since I can quite easily automate DNS entries for our managed domains) and then query the API for any breaches periodically!
Larry M. Smith commented
I understand that there exists the possibility of abuse here, but I am less interested in the data returning full email addresses for a domain search, but rather a count of unique email addresses per domain per object queried. I.e. I would query a breach for specific domains and only receive a count of the email addresses that exist in that breach.
After having my suggestion merged here and reviewing the dates of other posts, is this not likely to happen?
We subscribe to the multi-domain notifications so we can inform users of breached creds but getting to the data in an automated way doesn't seem possible with the current API version. Having to manually process the results is a pain and a bit clunky.
What I expected:
The ability to do a check for new breaches daily then the new content for our domains in them then do a check against AD for active users in a SOAR platform.
Inability to query API for breaches containing a single, or multiple domains so I could then query the individual breaches for relevant information. It appears the only solution for this would be to send a query for each active email in AD which would result in thousands of calls.
I support this idea as well
Search for pwned accounts across an entire domain using the API. Right now this option is only available through the website. It would be great to have this option available through the paid API as well :)
Any word on this? as Sean's comment mentions, it would be much better than needing to iterate through an organisation's active accounts. We are looking to implement something soon which will use the API to check any active accounts in our organisation against new breaches, but with domain search as an API option we'll just have to make lots of single calls.
Edit: appreciate that there's challenges involved with this - will proceed for now by checking one account at a time and observe the API rate limits.
I wonder how the Cyber Threat Intel companies are able to alert organizations with an export based on domains we pass along to them as keywords.
It would be perfect (for out use case) to offer some sort of org / user structure.
e.g. someone at domain (org) registers and validates ownership. This persons can then add / remove other users in org each with unique keys.
Obviously I'm aware this requires some retooling :) Good to hear there's something in the pipeline, Troy!
I'm keeping this idea open but also still under consideration. The main reason is that the present model of searching domains ensures the requestor still has control of the domain at the point of search. A persistent API key could still be used by someone who leaves the organisation and should no longer be authorised to access the data.
That's the background, there's a few things in the pipeline that *may* make this more feasible, but there's no timeline as of now.
I would love to be able to do a domain search for breaches and pastes using the API as well.
It would decrease the load on your (already very efficient from the cloudflare caching and Azure functions) system(s) and processing time on mine. What I have to do now is iterate over my active accounts and aliases, then send each one to the API with a 1600 ms delay in between so I can collect breach information about my organizations accounts. If there were 3487 accounts/aliases, that would take about 1.5 hours. And I miss out on breach and paste data about no longer active accounts in my domain.
If I could make an API call with the key you send me when you notify me of one of my active domain accounts showing up in a breach, I could get the data in one shot or two (one for pastes, one for breaches).
Where abc123def345ghi678jkl901mno234pqr5 is the key.
Using the key you send in the "Run another domain search" link button along with the domain, I'd be using a key that's already been created during the domain control verification process. I could send the domain as a second factor.
This feature is totally missing :( Update?
This would be cool! :D we need this.
This would be really appreciated. Even without SPLUNK I'd like the ability to check a domain against this database. Even if that means the results are partially anonymized. For example returning the amount of found mail addresses and in how many breaches total. Without returning the actual mail addresses would be great already.
Kenneth Jørgensen commented
Full support to this - could be really nice way of handling the data