Management of MFA Devices in AWS IAM

Just last week, AWS released a new feature to most AWS cloud customers — you can now assign multiple MFA devices to your root and other IAM users. Previously, due to just one device, you’d have to go through long procedures (often with no resolution) in case of lost devices, incorrect emails, and (privileged and uncooperative) ex-employees — well, no more.

While we’re at the subject; let’s have a quick refresher on management of MFA devices in IAM.

Creation of MFA Devices

Creation of a new MFA device generates the CreateVirtualMFADevice API call which contains everything about the affected user and referenced resources (the device added to the user in this case).

Here’s an excerpt from the CloudTrail entry against the API call which doesn’t actually log the user against which the device was created (though you can find the originator from the userIdentity key):

...    
  "requestParameters": {
        "path": "/",
        "virtualMFADeviceName": "root-account-mfa-device"
    },
    "responseElements": {
        "virtualMFADevice": {
            "serialNumber": "arn:aws:iam::{AccountId}:mfa/root-account-mfa-device"
        }
    }
...

Subsequently, you’ll also see the EnableMFADevice API call which suggests the newly created device was just enabled for usage (i.e., logins).

...
  "requestParameters": {
       "userName": "AWS ROOT USER",
        "serialNumber": "arn:aws:iam::{AccountId}:mfa/root-account-mfa-device"
    }
...

Let’s setup another device, generating the same set of events. Checking the logged call, I see the following parameters:

...   
  "requestParameters": {
       "path": "/",
        "virtualMFADeviceName": "another-device"
    },
    "responseElements": {
        "virtualMFADevice": {
            "serialNumber": "arn:aws:iam::{AccountId}:mfa/another-device"
        }
    },
...

ConsoleLogin Event Analysis:

As stated in the AWS news release already, ConsoleLogin events now include the MFA device used to authenticate to the user account as part of the call (log) as well. That’s a good addition as well.

For instance, if you don’t utilize an MFA device to authenticate, you’ll see it accordingly in the log:

...
    "additionalEventData": {
        "LoginTo": "https://us-east-1.console.aws.amazon.com/...",
        "MobileVersion": "No",
        "MFAUsed": "No"
    },
...

Similarly, using a device now references the MFA device in the call (which was previously created and enabled for usage):

...   
  "additionalEventData": {
        "LoginTo": "https://us-east-1.console.aws.amazon.com/...",
        "MobileVersion": "No",
        "MFAIdentifier": "arn:aws:iam::{AccountId}:mfa/another-device",
        "MFAUsed": "Yes"
    },
...

In case of a device breach or other reasons, you can easily disable the MFA device generating the DisableMFADevice and DeleteVirtualMFADevice API call. You can easily disable it by heading to the Security Credentials tab and selecting the device (Manage) under Multi-factor Authentication.

Logging in with the disabled device should now generate failed API calls against ConsoleLogin:

...    
    "errorMessage": "Failed authentication",
    "requestParameters": null,
    "responseElements": {
        "ConsoleLogin": "Failure"
    },
    "additionalEventData": {
        "LoginTo": "https://us-east-1.console.aws.amazon.com/...",
        "MobileVersion": "No",
        "MFAUsed": "No"
    },
...

It can also be monitored for as these actually indicate the right credential pair is being used just that the MFA code being entered is wrong or that the device doesn’t exist as it didn’t in our case — might warrant some form of action.