5\ Here is an example of this attack:
Pic 1: Pre-timestomped RUN key
Pic 2: Me running Joakim's tool
Pic 3: The timestomped registry key
6\ Detection Method 1: Windows EVTX
Event IDs 4656. 4757. 4660, 4663 do NOT detect this.
Look at ID 4657 - this event wont generate because it's alerting on a change to a registry VALUE, not the registry TIMESTAMP. This means enabling reg auditing won't detect this technique.
7\ Detection Method 2: Reg Discrepancies
For nested keys, the topmost key reflects the timestamp of the most recent subkey entry time. Unless each timestamp is timestomped, you can see that there is a time discrepancy.
NOTE: This detection WON'T work for keys with no subkeys.
8\ Detection Method 3: EDR
Running through procmon, one entry stood out which is the high-fidelity detection for this technique. You can see the KeySetInformationClass param from the "NtSetInformationKey" being used to write to a timestamp.
This is NOT normal behaviour!!
9\ I would finally detect on the use of the following APIs in conjunction:
10\ Finally, just an observation of mine... IR analysts are taught to look for timestomping of files by comparing $standard_information vs $filename. But there isn't a straight forward method of finding registry timestomping as it isn't as simple as parsing out MFT timestamps..
β’ β’ β’
Missing some Tweet in this thread? You can try to
force a refresh
2\ Most IR analysts are taught to detect timestomping using two methods:
> Compare $FI vs $SI times in the MFT
> Look for 0s in timestamp nanoseconds
These two detections are NOT foolproof - they will catch simple cases. Attackers can set nanoseconds and modify $FN time!
3\ Why should you care?
Most forensic courses teach these 2 detections without introducing more variables. A lot of analysts treat what they are taught as the "bible" without questioning it and when it comes to detecting these anomalies... critical evidence may be missed.
2\ Each process in Windows is represented by an "EPROCESS" structure.
These EPROCESS blocks are joined in a doubly linked list structure. The flink (forward link) tells you the next process running and blink (backwards link) tells you the previous process.
3\ When you see a list of processes on a live system, often times this is gathered by walking this doubly-linked structure of EPROCESS blocks.
Of course malware can unlink a process in this doubly linked list to hide from detection :P
1\ #MalwareAnalysis: Detecting Process Hollowing
The first pattern to look for are any calls to create processes in a suspended state:
> CreateProcessA
"dwCreationFlags" set 0x04 CREATE_SUSPENDED
Purpose is to disguise malicious code in a legit exe by replacing the contents.
2\ Following the process being started in a suspended state... (usually svchost.exe but who's counting). Then there are API calls to native/non native APIs:
3\ Other ones:
> NTResumethread
> NTwritevirtualmemory
> ntsetcontextthread
The logic is to look for signs of processes being started in suspended state - then the process being hollowed, replaced with "malicious" contents and resuming of execution.
Tracked by IoS:
> When you arrived
> When you left
> Long/Lat
πPhoto is a parsed local.sqlite file
2\ In your iPhone the local.sqlite will render like this - as you can see I went to a grocery store 13 times. I was in lockdown donβt judge me.
3\ You can parse these using DB browser for sqlite - there are field names including longitude, latitude and also tracks when you arrived / left so it understands your dwell time. There are also fields pertaining to vehicle events i.e. you parked your car.