Guest

Cisco Security

Cisco Firepower Threat Defense Forensic Investigation Procedures for First Responders


Introduction

Prerequisites

Step One - FTD Device Problem Description

Step Two - Document the FTD Runtime Environment

Step Three - FTD Image File Hash Verification

Step Four - Verify Digitally Signed Image Authenticity

Step Five - Verify Memory .text Segment Integrity

Step Six - FTD Crashinfo File/Core File

Step Seven - ROMMON Settings Check

Acknowledgments

Related Documentation

FTD Device Forensic Report Checklist

Revision History




Introduction

This document provides steps to collect forensic information from Cisco ASA devices running Firepower Threat Defense (FTD) Software when compromise or tampering is suspected. It outlines a number of commands that can be run to gather evidence for an investigation, along with the respective output that should be collected after running these commands. This document also provides information on how to perform integrity checks on FTD system images and includes procedures for collecting a memory dump, crashinfo file, and a core dump from an FTD device.

Note: Firepower Threat Defense (FTD) investigation procedures for the Firepower 2100, 4100, and 9300 series of platforms running the Cisco FXOS operating system are covered in a separate publication. 

IMPORTANT: DO NOT REBOOT THE DEVICE. Rebooting a device during initial assessment will irrevocably lose all volatile information contained within the device. (e.g. RAM contents, arp and routing tables, NAT translations, ACL hit and drop counts, etc.)

Note: It is highly recommended that a device suspected of tampering or compromise be isolated from the network prior to conducting an initial forensic examination. This may prevent remote unloading of any implants or malware installed on the device and will prevent an adversary from monitoring commands entered on the device under investigation.

If you require assistance or have questions regarding the following procedures, contact the Product Security Incident Response Team (PSIRT)

The main section of this document contains seven sections:

1.      FTD Device Problem Description Describe why the platform is a candidate for forensic examination.

2.      FTD Runtime Environment Collect platform configuration and runtime state.

3.      FTD Image File Verification Examine system image hashes for inconsistencies.

4.      Digitally Signed Image Verification Examine FTD system and running images for proper signing characteristics.

5.      Verify Memory .text Segment Retrieve and calculate a hash of the .text segment.

6.      Crashinfo / Core File Obtain a crashinfo dump and core file from the running FTD image.

7.      ROM Monitor Variables Examine ROM monitor settings for remote system image loading.


Prerequisites

The procedures described in this document assume the reader has a basic understanding of Cisco FTD Software command syntax.

A valid cisco.com account is required to view individual FTD Software and FTD firmware file hashes for software file integrity checking. For customers without a cisco.com account, a publicly available comprehensive list of file hashes (Bulk Hash File) can be downloaded from: https://www.cisco.com/c/en/us/about/trust-center/downloads.html

A Cisco Technical Assistance Center (TAC) service request (SR) is required for the device in question as the procedures outlined in this document assume that the information gathered in each step will be uploaded to a TAC SR to be subsequently analyzed by Cisco engineers for indications of compromise or tampering.


Step One FTD Device Problem Description

Describe in as much detail as possible WHY the device is a candidate for forensic examination. Are there configuration changes that cannot be explained? Is there unusual traffic originating from or terminating on the device? Are there anomalous entries in the device logs or in syslog messages? Is the device exhibiting odd behavior that cannot be attributed to a misconfiguration or a software or hardware defect?

Submit the problem description collected in this section to the relevant TAC SR and proceed to the next section of this document.


Step Two Document the FTD Runtime Environment

Complete the initial stage of forensic information gathering by issuing a show tech-support command and a dir all-filesystems command. Execute these commands from the privileged EXEC mode of the FTD diagnostic CLI. Some of the output may vary depending on the particular FTD Software version and/or features supported/configured on the device.

Execute the following command from the FTD CLI prompt:


system support diagnostic-cli

Execute each of the following commands in the diagnostic CLI and record the output:


enable
terminal pager 0
show tech-support detail
dir all-filesystems

The following list of commands should be executed to gather additional information relevant to the current operating state of the device. Although the output of these commands is not required to perform a forensic analysis of an FTD platform, it may provide additional information regarding any unauthorized changes made to the device if compromise is suspected.

Execution of the following commands in this section of Step 2 is optional:


terminal pager 0
show history
show clock detail
show startup-config
show reload
show process
show kernel process detail
show kernel ifconfig
show kernel module
show logging
show route
show eigrp nei
show ospf nei
show bgp summary
show arp
show ip address
show interface ip brief
show nat detail
show snmp-server user
show snmp-server group
show ipv6 interface brief
show ipv6 route
show conn all
show xlate
show aaa login-history

Submit all command output collected in this section to the relevant TAC SR and proceed to the next section of this document.


Step Three FTD Image File Hash Verification

Execute the following commands from the Cisco FTD CLI prompt:


system support diagnostic-cli
enable
show version

Note the location and filename of the FTD system image file and then execute the following command:


verify /sha-512 location:filename

Alternatively, an MD5 hash value can be calculated with the following command:


verify /md5 location:filename

After calculating the desired hash value(s), validate the digital signature of the file by issuing the following command:


verify location:filename

An example of this procedure is as follows:


> system support diagnostic-cli
Attaching to Diagnostic CLI ... Press 'Ctrl+a then d' to detach.
Type help or '?' for a list of available commands.
firepower> enable
Password:
firepower# show version 
-------------------[ firepower ]--------------------
Model                     : Cisco ASA5516-X Threat Defense (75) Version 6.2.3 (Build 83)
UUID                      : 1ebe4652-fef1-11e8-a7a7-a2be462dc9bc
Rules update version      : 2017-09-13-001-vrt
VDB version               : 290
----------------------------------------------------
Cisco Adaptive Security Appliance Software Version 9.9(2) 
Firepower Extensible Operating System Version 2.3(1.84)
Compiled on Sun 25-Mar-18 17:49 PDT by builders
System image file is "disk0:/os.img"
Config file at boot was "startup-config"

[output truncated]

firepower# verify /sha-512 disk0:/os.img
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
[OUTPUT TRUNCATED]
Done!

verify /SHA-512 (disk0:/os.img) = 
4cc897a4b15b8d9ef5a0ab7dd32c1a64d2a72aaa3363e3c392ee8b1d18a93c13f6f23a6355f0564b445d5c0daa2965860abba9845327366c1f1d1
3088ef21e0d firepower# verify disk0:/os.img Verifying file integrity of disk0:/os.img Computed Hash SHA2: 0ea0bf5c026e34ee9b7ba9925543f3f7 73e25c356c4e8717f9e9d2c0d9ed77f5 dfe67bcb5f58f4e5d1b950ec09f3d0be 7f0fa1e5bd98aaf1c2018fcb2e76fcd4 Embedded Hash SHA2: 0ea0bf5c026e34ee9b7ba9925543f3f7 73e25c356c4e8717f9e9d2c0d9ed77f5 dfe67bcb5f58f4e5d1b950ec09f3d0be 7f0fa1e5bd98aaf1c2018fcb2e76fcd4 Digital signature successfully validated

Repeat the procedure for any other system image file located on the file systems. A comprehensive list of all files can be viewed by executing the following command:


dir all-filesystems

If directed to do so, obtain a copy of the system image file and transfer it to a secure location if possible.


copy <location>:<system_image_filename.img> ftp: 
Address or name of remote host []? <destination_ip>
Destination filename []? </destination_ip></system_image_filename.img></location>

It is highly recommended that a hash value be calculated on the copied system image file and compared to the hash value obtained on the platform to ensure that no errors were introduced during the file transfer process.

The following example uses the sha512sum utility, which is included with most Linux distributions:


root@ftp-server:~# sha512sum os.img
4cc897a4b15b8d9ef5a0ab7dd32c1a64d2a72aaa3363e3c392ee8b1d18a93c13f6f23a6355f0564b445d5c0daa2965860abba
9845327366c1f1d13088ef21e0d os.img root@ftp-server:~#

Note that the FTD verify command and the sha512sum utility both produce an SHA-512 hash value of 4cc897a4b15b8d9ef5a0ab7dd32c1a64d2a72aaa3363e3c392ee8b1d18a93c13f6f23a6355f0564 b445d5c0daa2965860abba9845327366c1f1d13088ef21e0d for the os.img file in the previous output.

Submit all command output (including all computed hash values) and any system images collected in this section to the relevant TAC SRand proceed to the next section of this document.


Step Four Verify Digitally Signed Image Authenticity

Cisco FTD Software implements digitally signed system images on most platforms. Digitally signed Cisco FTD Software uses asymmetric (public-key) cryptography, which increases the security posture of Cisco FTD devices by ensuring that the system image has not been altered.

Certain ASA platforms running FTD Software, such as the newer Cisco 5500-X series, also support Secure Boot technologies. Cisco Secure Boot is a secure startup process that a Cisco device performs each time it boots up. Beginning with the initial power-on, a special purpose hardware device, known as the Trust Anchor module, verifies the integrity of the ROMMON code and the FTD image via digital signatures as they each are loaded. If any failures are detected, the user is notified of the error and the device will wait for the operator to correct the error. This prevents the network device from executing tainted network software.

For additional information see Trust Anchor Technology.

Note: The show software authenticity set of commands is only supported on FTD platforms that incorporate Cisco Secure Boot technologies.

The authenticity and integrity of a system image file can be verified by using the following commands:


system support diagnostic-cli
enable
show software authenticity file location:filename

An example of this procedure follows using the location and filename identified in step 3:


> system support diagnostic-cli
Attaching to Diagnostic CLI ... Press 'Ctrl+a then d' to detach.
Type help or '?' for a list of available commands.
firepower> enable
Password: 
firepower# show software authenticity file disk0:/os.img
File Name                     : disk0:/os.img
Image type                    : Release
    Signer Information
        Common Name           : abraxas
        Organization Unit     : NCS_Kenton_ASA
        Organization Name     : CiscoSystems
    Certificate Serial Number : 5AB844ED
    Hash Algorithm            : SHA2 512
    Signature Algorithm       : 2048-bit RSA
    Key Version               : A

The Organization Unit, Organization Name, and Certificate Serial Number values (highlighted in the previous output) can be viewed to verify that the system image signature is valid. It is also important to verify the authenticity and integrity of the running system image. This can be accomplished by using the following command:


show software authenticity running

An example of this procedure is as follows:


firepower# show software authenticity running           
Image type                    : Release
    Signer Information
        Common Name           : abraxas
        Organization Unit     : NCS_Kenton_ASA
        Organization Name     : CiscoSystems
    Certificate Serial Number : 5AB844ED
    Hash Algorithm            : SHA2 512
    Signature Algorithm       : 2048-bit RSA
    Key Version               : A

    Verifier Information
        Verifier Name         : ROMMON
        Verifier Version      : Cisco Systems ROMMON,1.1.13

The Organization Unit and Organization Name values (highlighted in the previous output) can be viewed to verify that the system image signature is valid. The certificate serial number should be the same as the value obtained from the show software authenticity file command. In the previous examples, the authenticity check of the FTD Software image on disk0 and the authenticity check of the running image both produce a value of 5AB844ED.

Lastly, obtain a copy of the public keys by using the following command:


show software authenticity keys

firepower# show software authenticity keys           
Public Key #1 Information
--------------------------
Key Type              : Release (Primary)
Public Key Algorithm  : 2048-bit RSA
Modulus :
        96:A2:E6:E4:51:4D:4A:B0:F0:EF:DB:41:82:A6:AC:D0:
        FC:11:40:C2:F0:76:10:19:CE:D0:16:7D:26:73:B1:55:
        FE:42:FE:5D:5F:4D:A5:D5:29:7F:91:EC:91:4D:9B:33:
        54:4B:B8:4D:85:E9:11:2D:79:19:AA:C5:E7:2C:22:5E:
        F6:66:27:98:1C:5A:84:5E:25:E7:B9:09:80:C7:CD:F4:
        13:FB:32:6B:25:B5:22:DE:CD:DC:BE:65:D5:6A:99:02:
        95:89:78:8D:1A:39:A3:14:C9:32:EE:02:4C:AB:25:D0:
        38:AD:E4:C9:C6:6B:28:FE:93:C3:0A:FE:90:D4:22:CC:
        FF:99:62:25:57:FB:A7:C6:E4:A5:B2:22:C7:35:91:F8:
        BB:2A:19:42:85:8F:5E:2E:BF:A0:9D:57:94:DF:29:45:
        AA:31:56:6B:7C:C4:5B:54:FE:DE:30:31:B4:FC:4E:0C:
        9D:D8:16:DB:1D:3D:8A:98:6A:BB:C2:34:8B:B4:AA:D1:
        53:66:FF:89:FB:C2:13:12:7D:5B:60:16:CA:D8:17:54:
        7B:41:1D:31:EF:54:DB:49:40:1F:99:FB:18:38:03:EE:
        2D:E8:E1:9F:E6:B2:C3:1C:55:70:F4:F3:B2:E7:4A:5A:
        F5:AA:1D:03:BD:A1:C3:9F:97:80:E6:63:05:27:F2:1F
Exponent              : 65537
Key Version           : A
Public Key #2 Information
--------------------------
Key Type              : Release (Backup)
Public Key Algorithm  : 2048-bit RSA
Modulus :
        96:A2:E6:E4:51:4D:4A:B0:F0:EF:DB:41:82:A6:AC:D0:
        FC:11:40:C2:F0:76:10:19:CE:D0:16:7D:26:73:B1:55:
        FE:42:FE:5D:5F:4D:A5:D5:29:7F:91:EC:91:4D:9B:33:
        54:4B:B8:4D:85:E9:11:2D:79:19:AA:C5:E7:2C:22:5E:
        F6:66:27:98:1C:5A:84:5E:25:E7:B9:09:80:C7:CD:F4:
        13:FB:32:6B:25:B5:22:DE:CD:DC:BE:65:D5:6A:99:02:
        95:89:78:8D:1A:39:A3:14:C9:32:EE:02:4C:AB:25:D0:
        38:AD:E4:C9:C6:6B:28:FE:93:C3:0A:FE:90:D4:22:CC:
        FF:99:62:25:57:FB:A7:C6:E4:A5:B2:22:C7:35:91:F8:
        BB:2A:19:42:85:8F:5E:2E:BF:A0:9D:57:94:DF:29:45:
        AA:31:56:6B:7C:C4:5B:54:FE:DE:30:31:B4:FC:4E:0C:
        9D:D8:16:DB:1D:3D:8A:98:6A:BB:C2:34:8B:B4:AA:D1:
        53:66:FF:89:FB:C2:13:12:7D:5B:60:16:CA:D8:17:54:
        7B:41:1D:31:EF:54:DB:49:40:1F:99:FB:18:38:03:EE:
        2D:E8:E1:9F:E6:B2:C3:1C:55:70:F4:F3:B2:E7:4A:5A:
        F5:AA:1D:03:BD:A1:C3:9F:97:80:E6:63:05:27:F2:1F
Exponent              : 65537
Key Version           : A

Submit all command output and any system images collected in this section to the relevant TAC SR and proceed to the next section of this document.


Step Five - Verify Memory .text Segment Integrity

Execute the following commands from the Cisco FTD CLI prompt:


system support diagnostic-cli
enable

Then calculate a hash value for the .text memory segment and retrieve a copy of it by executing the following commands:


verify /sha-512 system:memory/text
copy system:memory/text ftp

An example of this procedure is as follows:


> system support diagnostic-cli
Attaching to Diagnostic CLI ... Press 'Ctrl+a then d' to detach.
Type help or '?' for a list of available commands.
firepower> enable
Password: 
firepower# verify /sha-512 system:memory/text !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 
[output truncated]
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!Done!
verify /SHA-512 (system:memory/text) = 
a03a15444f0995f578e9aa6cbc8feed2a3f2dd8ac8cca919b7b2b54836ba3d4b763372f58029e66fa64aafa8eea
2b79d5f0c7ea65cde0d813aef17e436e49b85 firepower# copy system:memory/text ftp Source filename [memory/text]? Address or name of remote host []? 10.10.10.1 Destination filename [text]? system.memory.text.bin !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! INFO: No digital signature found 71921664 bytes copied in 2.60 secs (35960832 bytes/sec)

It is highly recommended that a hash value be calculated on the copied memory segment file and compared to the hash value obtained on the platform to ensure that no errors were introduced during the file transfer process.

The following example uses the sha512sum utility, which is included with most Linux distributions:


root@ftp-server:~# sha512sum system.memory.text.bin
a03a15444f0995f578e9aa6cbc8feed2a3f2dd8ac8cca919b7b2b54836ba3d4b763372f58029e66fa64aafa8eea
2b79d5f0c7ea65cde0d813aef17e436e49b85 system.memory.text.bin root@ftp-server:~#

Note that the FTD verify command and the sha512sum utility both produce an SHA-512 hash value of a03a15444f0995f578e9aa6cbc8feed2a3f2dd8ac8cca919b7b2b54836ba3d4b763372f58029e66fa 64aafa8eea2b79d5f0c7ea65cde0d813aef17e436e49b85 for the system.memory.text.bin file.

Submit all command output (including all computed hash values) and any system images collected in this section to the relevant TAC SR and proceed to the next section of this document.


Step Six FTD Crashinfo File/Core File

WARNING: Executing the tasks in this section will trigger a reload of the FTD platform.

Cisco recommends performing this task during a maintenance window. Cisco does not recommend performing this task if additional forensic information needs to be collected because a reload of the device may cause the loss of information vital to a forensic investigation. Please ensure that you have a copy of the original device configuration and the appropriate authorization to initiate a reload of the platform in question prior to proceeding with this step.

This step describes how to obtain a crashinfo file from a Cisco FTD device. The crashinfo dump is saved in the root of the Cisco FTD file system by default and the storage space required may vary from several hundred megabytes to several gigabytes in size depending on device model. Be sure that there is enough space on the destination FTD flash or disk file system to accommodate the crashinfo dump file.

To initiate the crashinfo dump process, execute the following commands:


system support diagnostic-cli
enable
crashinfo force page-fault

An example of this procedure is as follows:


> system support diagnostic-cli
Attaching to Diagnostic CLI ... Press 'Ctrl+a then d' to detach.
Type help or '?' for a list of available commands.
firepower> enable
Password: 
firepower# crashinfo force page-fault 
WARNING: This command will force a crash and cause a
         reboot. Do you wish to proceed? [confirm]: 

Register dump: Thread DATAPATH-1-4679 in thread group
other: Unknown
        r8 0x0000000000000001
        r9 0x0000000000000000
       r10 0x00002afa53d2f488
       r11 0x0000000000000000
       r12 0x00002afa53d2f540
       r13 0x0000000000000000
       r14 0x00000000000000c8

[output truncated]

Begin to dump crashinfo to flash....

End of console dump.
Do 'show crashinfo' after reboot to retrieve other crash information
Process shutdown finished
Rebooting... (status 0x8b)

When the crashinfo dump process is complete, the FTD platform will reboot.

The crashinfo dump is written to a file located on the FTD file system with the following format: crashinfo_<date>_<time>_<timezone>. The name of the file can be displayed using the following command:


dir

> system support diagnostic-cli
Attaching to Diagnostic CLI ... Press 'Ctrl+a then d' to detach.
Type help or '?' for a list of available commands.
firepower> enable
Password: 
firepower# dir
Directory of disk0:/

86     -rwx  103582240    00:55:18 Mar 26 2018  os.img
87     -rwx  47           14:54:27 Jan 07 2019  .boot_string
88     -rwx  152137       16:03:48 Dec 13 2018  install.log
15     drwx  4096         22:39:18 Jan 02 2019  log
23     drwx  4096         16:21:00 Dec 13 2018  crypto_archive
24     drwx  4096         16:21:02 Dec 13 2018  coredumpinfo
90     -rwx  103582241    18:17:16 Jan 03 2019  os2.img
91     -rwx  482482       14:00:56 Jan 07 2019  crashinfo_20190107_140035_UTC

5 file(s) total size: 207799147 bytes
7864668160 bytes total (7656325120 bytes free/97% free)

It is highly recommended that hash values be calculated on the crashinfo files obtained in this section so that any errors introduced by subsequent copying or transmission can be reliably detected.


firepower# verify /sha-512 disk0:/crashinfo_20190107_140035_UTC 
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Done!
verify /SHA-512 (disk0:/crashinfo_20190107_140035_UTC) = 
b2a15388933659df631378f03654c71bc7016852d74dcab4077eef24374163158cb3c1b86ecc0bf467367b1756e82b113a5a9f5ae
789d0403053d03b70aa

After calculating the hash value of the crashinfo file on the FTD platform, copy the crashinfo file to a secure location and calculate the hash value again.

The following example uses the sha512sum utility, which is included with most Linux distributions:


root@ftp-server:~# sha512sum crashinfo_20190107_140035_UTC
b2a15388933659df631378f03654c71bc7016852d74dcab4077eef24374163158cb3c1b86ecc0bf467367b1756e82b113a5a9f5ae
789d0403053d03b70aa398a crashinfo_20190107_140035_UTC root@ftp-server:~#

Note that the FTD verify command and the sha512sum utility both produce an SHA-512 hash value of b2a15388933659df631378f03654c71bc7016852d74dcab4077eef24374163158cb3c1b86ecc0bf4 67367b1756e82b113a5a9f5ae789d0403053d03b70aa398a for the crashinfo_20190107_140035_UTC file.

Next, enter FTD expert mode and copy the core file to disk0 so that it can be copied off the platform by executing the following command:


expert

Note: the sudo su - command must be executed after entering expert mode to ensure that the correct privileges are obtained to copy the core file from one disk partition to another.

An example of this procedure is as follows:


> expert
admin@firepower:~$ sudo su -
root@firepower:~# cd /ngfw/var/common
root@firepower:/ngfw/var/common# ls -la
total 973208
drwxrwxr-x  2 root detection       4096 Apr 25 20:24 .
drwxr-xr-x 13 root root            4096 Apr 22 19:52 ..
-rw-------  1 root root      1491251200 Jan  7 14:01 core_1546869661_firepower_lina_11.4411

root@firepower:/ngfw/var/common# cp core_1546869661_firepower_lina_11.4411 /mnt/disk0/.
root@firepower:/ngfw/var/common# exit
logout
admin@firepower:~$ exit
logout

After the core file has been copied to disk0, copy the core file to a secure location. The following example transfers the file using the secure copy command:


> file secure-copy 10.10.1.1 root /tmp core_1546869661_firepower_lina_11.4411
root@10.10.1.1's password: 
copy successful.

It is highly recommended that hash values be calculated on the core files obtained in this section so that any errors introduced by subsequent copying or transmission can be reliably detected.

Submit all command output, hash values, crashinfo and core files collected in this section to the relevant TAC SR, and proceed to the next section of this document.


Step Seven ROMMON Settings Check

The ROM monitor firmware of the FTD platform is executed when the FTD is powered up or reset. The firmware initializes the platform hardware and boots the FTD operating system software. Because the ROM monitor settings are persistent if they have been synced to NVRAM, information about the ROM monitor variable values could indicate an attempt to influence the Cisco FTD boot sequence. The set command can be used while in the ROM monitor prompt to see the value of the ROM monitor variables.

ROM monitor mode is accessed by rebooting the FTD device and pressing the BREAK or ESC key during the reload process when prompted as depicted in the following example:


> reboot
This command will reboot the system.  Continue?
Please enter 'YES' or 'NO': yes

Broadcast messagStopping Cisco ASA5516-X Threat Defense...
Shutting down sfifd...                                                [  OK  ]
Clearing static routes
Unconfiguring default route                                           [  OK  ]
Unconfiguring address on br1                                          [  OK  ]
Unconfiguring IPv6                                                    [  OK  ]
Downing interface                                                     [  OK  ]
Stopping xinetd: 

[output truncated]

Rebooting...
Rom image verified correctly
Cisco Systems ROMMON, Version 1.1.13, RELEASE SOFTWARE
Copyright (c) 1994-2017  by Cisco Systems, Inc.
Compiled Mon 10/16/2017 17:54:58.29 by wchen64

Current image running: Boot ROM0
Last reset cause: PowerCycleRequest
DIMM Slot 0 : Present
DIMM Slot 1 : Present

Platform ASA5516 with 8192 Mbytes of main memory
MAC Address: 70:b3:17:ce:ba:7d

Use BREAK or ESC to interrupt boot.
Use SPACE to begin boot immediately.
Boot interrupted.  
rommon 1 >

The following example shows the output of the ROM monitor set command on a Cisco FTD platform:


rommon 1 > set
    ADDRESS=
    NETMASK=
    GATEWAY=
    SERVER=
    IMAGE=
    CONFIG=
    PS1="rommon ! >

The previous example depicts a platform where the ROM monitor values are at their default values and have not been altered.

To return the FTD platform to normal operation, simply issue the boot command at the ROM monitor prompt as depicted in the following example:


rommon 2 > boot
Located '.boot_string' @ cluster 283386.
#
Located 'os.img' @ cluster 257862.
#############################################################################
#############################################################################
LFBFF signature verified.
INIT: version 2.88 booting

[output truncated]

Submit all command output obtained in this section to the relevant TAC SR.


Acknowledgments

The author would like to thank all members of the Customer Experience Security Programs (CXSP) and Advanced Security Initiatives Group (ASIG) who provided their expertise for this document. A special note of thanks to Jason Barnes of ASIG whose contributions greatly enhanced the efficacy of the forensic procedures contained in this publication.