Tools · Forensics tools · 18 / 25
CyberChef: raw clocks, epochs, and case time
Unix time and Windows FILETIME are numbers you will find in logs and registry extracts. Convert them, then apply the same timezone you set in Autopsy before you put a clock time in the report.
Unix time counts seconds from 1970
A Unix timestamp is a count of seconds since 1970-01-01 00:00:00 UTC. Ten digits covers recent years. Thirteen digits is usually milliseconds, and you divide by 1000 or use the operation that expects milliseconds. From UNIX Timestamp in CyberChef turns the number into a UTC date. 1776258300 is 2026-04-15 13:05:00 UTC. That conversion is arithmetic, and it is UTC. It is not yet Brooklyn wall time.
If the field is a string of digits inside a larger line, slice it out. Feeding the whole CSV line to a timestamp operation will interpret the wrong digits. The input file for this recipe is the digits alone, and the note says which column they came from.
FILETIME counts 100-nanosecond ticks from 1601
Windows FILETIME is a 64-bit count of 100-nanosecond intervals since 1601-01-01 UTC, stored little-endian when you meet it as raw bytes. Eight bytes, little-endian, are the field. CyberChef can turn that value into Unix time and then into a date. The number 134207319000000000 is the same instant as 1776258300: 2026-04-15 13:05:00 UTC. The little-endian bytes are 00 a6 40 77 d8 cc dc 01. If you reverse the endianness you will get a date in another century, which is your signal to flip them back and record which endianness the source uses.
Registry extracts and some EVTX renderers already convert FILETIME to text. When they do, you do not convert again. Read the rendered time and its zone. Raw bytes from a structure you carved are the case for this recipe. The disk timestamps in Autopsy are already converted from NTFS, which is also UTC internally. You are aligning clocks, not discovering a new one.
Unix seconds: 1776258300 UTC: 2026-04-15 13:05:00 FILETIME: 134207319000000000 LE bytes: 00 a6 40 77 d8 cc dc 01
Apply America/New_York once
The case timezone is America/New_York. In April that zone is four hours behind UTC, so 13:05 UTC is 09:05 Brooklyn. Write both if there is any chance of confusion, and mark which one the report’s timeline uses. A Sysmon event that already says UtcTime is UTC. Subtract the offset once. Adding the offset because the number “looked early” will invent a second event.
Daylight time is why you name the zone and the date rather than a fixed minus-five. A January event on the same laptop is five hours behind UTC. The recipe can emit UTC, and the case note applies the zone for that date. If CyberChef’s display zone is the lab laptop’s zone, look twice. The operation’s UTC output is the portable one to paste.
Put the converted time on the right row
A converted clock joins a specific artifact. The FILETIME from a registry value is that value’s time, if the structure says so. It is not automatically the workbook’s created time. You already have M, A, C, and B from Autopsy. Add a converted field only next to the source it came from. If two sources disagree by hours and the offset is exactly the zone error, you may have converted one of them twice. Check that before you write a finding about clock tampering.
Save the recipe that takes the eight raw bytes to a UTC string. It is short, and it is the kind of chain another examiner will rerun when they doubt your arithmetic. The prose can carry the Brooklyn conversion so the zone decision stays in the case log next to the Autopsy timezone line.
Worked case: 13:05 UTC is 09:05 in the case zone
A registry export from the image includes the little-endian bytes 00 a6 40 77 d8 cc dc 01 on a value you are checking. From Hex, then the FILETIME conversion, yields 2026-04-15 13:05:00 UTC. You write 09:05 America/New_York beside it and cite the value name. The workbook’s $FILE_NAME time is 09:14 Brooklyn, so this value is earlier in the same morning, and it stays attached to the registry source.
You do not move the workbook’s timestamp. You add one more sourced clock. The recipe and the eight input bytes go in the export folder as their own triple, separate from the Base64 command-line recipe.
Diagram
The same instant as a Unix count and as FILETIME
2026-04-15 13:05:00 UTC
Digits. 1776258300
Epoch. Seconds since 1970-01-01 00:00:00 UTC.
Case time. 09:05 America/New_York on that April date.
Ticks. 134207319000000000
Bytes. Eight little-endian bytes: 00 a6 40 77 d8 cc dc 01.
Case time. The same 09:05 America/New_York, if endianness was read correctly.
Check yourself
1. From UNIX Timestamp turns 1776258300 into 2026-04-15 13:05:00 UTC. The case zone is America/New_York in April, which is four hours behind UTC. What time do you put on the Brooklyn timeline?