There are several methods to audit database transactions, but they all affect performance more or less
SQL Server Change Tracking and SQL Server Change Data Capture don't show who, when, and how executed the transactions. On the other hand, SQL Server Change Data Capture shows the old and new values for the UPDATE statements. Here is a useful set of comparison notes: SQL Server 2008 Change Tracking (CT) and Change Data Capture (CDC) and Comparing Change Data Capture and Change Tracking
SQL Server Auditing shows who, when, and how, but doesn't show the old and new values for the UPDATE statements
The methods that read the database transaction log files don't add overhead, as there is not additional change capturing. Besides fn_dblog, that can return results not easy to understand, there are third party tools, such as ApexSQL Log
There are two more auditing tools from ApexSQL - ApexSQL Audit which uses triggers, so can impact performance on a high transaction database, and ApexSQL Comply that uses SQL traces
SQL Server database auditing techniques
Disclaimer: I work for ApexSQL as a Support Engineer
If I'm not mistaken the default trace contains property changes to logins which should include an account being disabled. An article that walks though the various information you can get from the default trace.
EDIT
OK, already confirmed not much at all is captured with manipulating logins on an instance. So unless you had something already capturing the information like SQL Server Audit (if on 2008 or higher), there is nothing natively logged by SQL Server to let you know who did it.
If you happen to be logging successful logins to that instance you can determine who was logged in that had the permissions but that is the closest you will likely get.
Best Answer
That is exactly what SQL Auditing is for :-) Now you can finally know WHO did what with a user's access and many more objects in the server or at the database level. However, Auditing does need to be setup first before it can record the results.
Specifically speaking of Database level audits: "The database audit specification collects database-level audit actions raised by the Extended Events feature. You can add either audit action groups or audit events to a database audit specification. Audit events are the atomic actions that can be audited by the SQL Server engine. Audit action groups are predefined groups of actions. Both are at the SQL Server database scope. These actions are sent to the audit, which records them in the target."
You can read more here https://docs.microsoft.com/en-us/sql/relational-databases/security/auditing/sql-server-audit-database-engine?view=sql-server-ver15