Hello
I have sometimes seen contextually small and recently-created setupapi.dev.log files , but they always had a larger "cousin" or predecessor
I recall that setupapi.dev.log would be re-named when it reached a certain size (although I don't recall what that size was) and a new setupapi.dev.log was created, carrying on from where the old file left off. I also don't recall the exact formatting of the modified filename but it started with setupapi and was located alphabetically adjacent to setupapi.dev.log in the \Windows\Inf folder
I'm now looking at a DD image of a Win7 Enterprise system where setupapi.dev.log is only 476 bytes, the first entry is dated 17th April 2019 but the computer has been in use for a lot longer than that. And the "cousin" isn't present
There is a setupapi.offline.log which I have just started reading about but there's a 2-year gap between it's last entry and the first one in setupapi.dev.log. And, the first entry in setupapi.offline.log in 2011 which makes no sense as the Dell warranty didn't start until 2015. We're in a corporate environment where a 3rd party vendor tests and provides the standard images/builds
Has anyone come across this before and have any idea what possible causes there could be (other than manually deleting the re-named setupapi.dev.log, which is always a possibility)
One of the results of this is that I am currently unable to see when devices were first installed using my normal process (as per SANS and others).
Look forward to replies )
Peter
I'm now looking at a DD image of a Win7 Enterprise system
We're in a corporate environment where a 3rd party vendor tests and provides the standard images/builds
Just to clarify. Server or Desktop PC?
It's a Laptop
I've never come across Win7 Enterprise Servers…………………
It's a Laptop
Do you know if there is any system maintenance tasks operating on the system?
No I don't know. Sorry to confess my ignorance, what kind of tasks would I be looking for and how would I find out. Am happy to be pointed in the direction of the well rather than been lead to drink
Am happy to be pointed in the direction of the well rather than been lead to drink
lol
Please correct if wrong/inaccurate (remember I know nothing of your circumstances other than those in your post)
The impression from your post is that this is a stand-alone device not administered by the organisation's system administrator or by RSAT.
Please confirm how image/build occurred
1) 'Grub' on micro-card- needed at power up password and other credentials to assist machine download image/build from local or distant server?
2) Set-up network connection to local/distant server?
3) image/build transferred from physical-connect device?
4) Some other method?
If you cannot answer any of the above questions then in the alternative can you provide content (from e.g. below) which might give a clue during any rollback
- setupmem.dmp
- .evtx file/s
- setupapi. app. log
- setupapi.dev.log
- setupapi.offline.log
- setupact.log
- setuperr.log
- DISM.log
- CBS.log
- cbs.unattended.log
- Sessions.log
Is this post connected to the exchanges of views in an earlier post at FF of yours?https://www.forensicfocus.com/Forums/viewtopic/t=12079/postdays=0/postorder=asc/start=0/
Has anyone come across this before and have any idea what possible causes there could be (other than manually deleting the re-named setupapi.dev.log, which is always a possibility)
I haven't seen this before, but have you considered creating a timeline of system activity? I'd think that file system metadata, correlated with Windows Event Log and Registry metadata, might be very revealing, particularly with respect to what was going on on the system when the file was created or modified.
I haven't seen this before, but have you considered creating a timeline of system activity? I'd think that file system metadata, correlated with Windows Event Log and Registry metadata, might be very revealing, particularly with respect to what was going on on the system when the file was created or modified.
Uncommon event but experience from previous work for image/builds on new systems or updating older ones it was found that the image that had been "baked" at first instance was flawed (causing glitches and other device issues) which the 3rd party then went to site to make changes and modify certain .logs and files. This is where I thought this matter might be going.
Some of the .logs in my list above were compiled using tips and hints from one of your books, Harlan.
I did think later that maybe include in the search for artifacts might find leads also at
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Uninstall
and as this is Windows 7 to look at 'AMCACHE'
C\Windows\AppCompat\Programs
RecentFileCache.bcf
AEINV_PREVIOUS.xml
AEINV_WER_{MachineId}_YYYYMMDD_HHmmss.xml
The drawback here, of course, is the OP couldn't answer is whether the system had been controlled by system admin settings or any system maintenance tasks operating on the system so these would need checking?
[quote="trewmte]The drawback here, of course, is the OP couldn't answer is whether the system had been controlled by system admin settings or any system maintenance tasks operating on the system so these would need checking?
Yes sorry about that, been somewhat snowed under. In reply to your questions, I really don't know. Our relationship with the 3rd party is not good, I'll ask the question but won't hold my breath for them even understanding the question
Peter
and as this is Windows 7 to look at 'AMCACHE'
C\Windows\AppCompat\Programs
RecentFileCache.bcf
AEINV_PREVIOUS.xml
AEINV_WER_{MachineId}_YYYYMMDD_HHmmss.xml
Also, the Syscache hive and the "HKLM\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\CIT\System" key.