As others already pointed out, we do not normally assign an overarching name to these functions. I have heard all of these terms and seen them in action, but so far, no common name that crossed language/platform/framework boundaries seems to have emerged as far as I can tell. But I think it's a fine question nevertheless. As it was said, naming things is hard, but we all agree that it is also important, so here's my take on this:
Hooks are as @Kilian Foth pointed out quite the old-school term and indeed, I haven't heard that term in a long time. There's not really a reason why it went out of fashion as it is still valid, though I have to admit I never really liked the idea of a visual hook for this sort of concept.
Handlers have been named too, however, these do in general have a slightly different semantics in most of the cases I encountered them. Handlers are typically found in correspondence to user interactions (action / button handlers). Event handlers are a slightly more targeted term, which directly corresponds to events. Due to many domains explicictly modelling events, however, I also don't like that as a general term, since it can be confusing to have "event handlers" in the hook/callback sense, when there is no actual "event" involved.
Callbacks are close to hooks, but due to the term have a different directional emphasis. With a hook there is something existing and from the outside you hook into that, whereas a callback is something you pass along and at some time lateron, the other side will reach out to your callback. Other than that, callbacks have fallen out of fashion similarly to hooks with derogatory derived terms like "callback hell" coming to mind.
"Implicitly" is yet another term that already exists for such a case, yet has again a completely different semantics. Check out the Scala language, which offers "implicitly" as a direct language term even. Its meaning though is not that of a hook/callback/whatever we discuss here.
In addition to that, several frameworks do not even bother with names for this purpose. A typical case is the usage of f.ex. Java's reflection API. Consider the Beans standard, in which you have accessor methods (a.k.a. getters). Several frameworks call these methods automatically via reflection and they serve yet another purpose in contrast to all of the above.
As a consequence of this discussion, I would like to argue Obi-Wan-style, that this term is not what you're looking for. As we have seen, the different candidate terms have wildly differing semantics or reasons for being called automatically. It is even disputable what "automatic" means. Since naming is primarily a means to transport meaning, the very use of a term denoting "automatically used function" is questionable.
As soon as you fix some of these variable semantical interpretation options (or if you prefer UML "semantic variation points") though, a term to identify your choices starts to make sense. That's why we do have hooks, event handlers, callbacks, implicit methods, property accessors and what-not. But each of these terms contains more information than the mere fact of "automatic calling", whatever that may be.