I think from a security standpoint , you already have enabled MFA and changed the passwords so this must take care of future attacks. Another thing I would suggest you to run is Revoke-AzureADUserAllRefreshToken cmdlet to clear any and all refresh tokens for this user in any browser session etc. You would need to download and install Azure AD powershell 2.0 for running this against your Azure AD environment .
Coming to the API key question. I would suggest you to check the apps user had created. I do not have a ready script for that but you can use the Get-AzureADapplicationOwner cmdlet to find the same. Yes, API key is independent of the password for the user so if an API was created earlier , it would work . But after password change no new API key could be generated. If the attacker had already generated API key and an app then we have a problem . API key is always created for a application object. It cannot be per user. If you periodically do Application audits for your azure AD to find out what all application user have registered then you may know what all this user have registered. Also for getting the permissions to act on behalf of this user , the attacker may need multiple delegated and application permissions on different API(or on Microsoft Grpah API) with Administrator consent Grant . Generally consent grant is available for most of the application level API permissions. And the IAM team in every company maintains data on what all application were consented for which all permissions to keep a track . I think if you have this in place you can just go back to the systems and find out what all admin consent requests were generated by this user . If you do not have this then you may need to check each and every app which was created since you detected the compromise of password. Since its phishing , you would be able to know the tie when the phishing mail landed in the inbox. You can check the directory audit log to find what all apps were created and what all admin grants were requested within that period. .If you find anything within that audit log then you can remove the old keys for the application and setup new keys and inform stakeholders. However if you do not find anything in audit log then I think you should be good as I am assuming the user did not have administrator access.
hope the above provides you the insights you were looking for. In case you have any further query , please do let us know. If the answer is helpful please do accept this as answer. If you have found something new or this answer does not help you , please do let me know in comments and we will continue to help you on this. If you have additional information that you have found , please do post it to share with the whole community for everybody's benefit as the security breaches and incident response can give everyone an Idea on how to tackle the same. It may be helpful to our readers.