In our case, all signups, password changes, etc. are done through main web sites (that the forums are a part of) which controls XF for us. It doesn't look like our Ukraine friends have tried to change any of the passwords yet (which would require manually going to the main site...). For our three user accounts that got breached (as mentioned above), the third user never actually logged onto the forum. The bot did, which thus automatically created the XF account since it existed in our main DB (accounts on XF are automatically created on first login to the forums if accounts exist on the main site). That's very interesting, as the bot looked like it was scanning our forums for usernames to compare to its database and then trying some. This third account doesn't fit into this theory. It is interesting that over 600 pages were scanned, 19 login attempts, with at least 3 username successes... however, 4 of the 19 were for this same username (third user). I haven't checked the other 2 usernames yet, but if if at least 6 of the 19 login attempts were successful... it is notable. It is interesting that there are so very few attempts and such a high percentage of attempts successful. It makes me wonder if the users in question had some passwords saved in a password utility on or off their computers that was breached... If that was the case, it's not yet a given they will appear in the pawned DBs.
As far as blocking vs not blocking IPs... it depends on your use case and plans. For many XF admins, it probably does make sense to keep that IP open for now. However, if you have enough policies and tech in place to inactivate stale accounts and track activity and more, then there are arguments that can be made to block. Admittedly, this probably isn't the case for most users yet.
We spent the day writing scripts and scrubbing data back to last summer. There were other Ukraine attempts, but only these 3 (from this single IP) appear successful.
In regards to a comment above, comparing logins to a pawned db has problems in and of itself, including decisions on how to handle matches especially since the positive hit rate is expected to be high. Matches aren't made for breaches from your site, but credential/pw combos in some cases, and for the most public APIs, just for password hashes. With so many breaches out there and so many of our users re-using passwords from site to site, and notably, totally different people choosing the same passwords, it's going to be an issue.
We've written XF addons before for our customer and internal use. We'll considering writing another now for wider distribution (here) and a February release. We are still crunching data first though. At the end of the day, I think as close to a solution as we can get is going to depend on attacking the problem on multiple fronts...