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
The capabilities of the leaked Chinese APT contractor "iOS Spyware" are accessing:
- basic mobile phone data
- GPS location
- Contacts
- Photos / multimedia files
- Recording sounds
If this sounds familiar, it should. These are settings accessible...Accessible ANY application requesting these permissions on a phone :)
This means, the delivery for the "spyware" would likely (my guess) be in the form of an application that the user installs on their device and must approve these permissions. If you've ever done mobile forensics, this is almost one of the first things you would check.
3\ The implantable devices are very similar in concept to the Hak5 devices.
This is not a new attack vector and NOT novel.
However, this should serve as a push for businesses to consider their threat models and playbooks for this kind of event.
Specifically the vendor's devices are disguised as:
- A power strip
- A power adapter
The way they work (as per the document) is: 1. Cracks WiFi password, sets up socks proxy 3. Cracks routing device 4. Self destruction to clear all system data
From an ops standpoint this targets a weak point of most businesses as most orgs do not have the best logging set up for their peripheral devices. It's why a lot nation states target edge devices for initial access (EDR blindspot / logging blindspot and difficulty of analysis for blue teamers).
However, once they pivot onto a vulnerable device or onto the network... the work of the detection team stays the same, it may just be difficult (in the absence of logs) to piece together what occurred.
2\ EWS and other legacy auth is commonly abused by APT groups (when enabled).
Check MSExchange Management.evtx log for EWS abuse.
Look for cmdlets like (more cmdlets in blog)
> New-MailboxExportRequest
> Remove-MailboxExportRequest
> Search-Mailbox
> Set-Mailbox
3\ Hunt IIS logs in Exchange for:
> Exploitation of unpatched vuln
> Webshell/owa backdoors being used
> Exfil
I've noted across engagements this happens in chunks via several extensions 7Z, TAR, RAR, PST, OST, CAB, ZIP). APTs will use several diff file types on one engagement