I need some help guys. Here is the story
I maintain my company's Intranet and this one time I noticed something really strange. About 11ish in the morning I found out that my web pages have gone bad, the contents of the pages were of the last year (2007), about a month or 2 BEFORE I became the web guy.

I thought maybe the IIS was pointing to some old directories, because I was just working on the pages and they were fine. Turned out that IIS was just fine, the files on the web server however were replaced by files with contents from the past. I thought I may have accidentally replaced the file myself (love the Ctrl+C and V).

I looked at the date of the files 01/15/2008 10:52am, hmm interesting it was only a moment ago, feeling compelled to correct the issue I copied the *weird* files to a folder and replace them with the correct files from my machine. No big deal... BUT I am still puzzled as to how it happened in the first place. I don't keep files that old with me, not to mention I was not working as the web guy at the time when those contents were generated.

My biggest question is: how do I find out who replaced the files. This is a company Intranet setting and only a handful of people have access to the web server. For people who have access they simply use Windows Explorer to navigate to the folder without logging in. Is there a log to find out who change what? The files property didn't tell me anything. To keep it simple if I replaced a file on the server, is it logged at all?

I don't even bother with the Network Administrator, they are practically clueless.

Dani AI

Generated

Since later traced this to a restore from SourceSafe, here are concise, practical steps and sane policies to prevent a repeat and to preserve evidence if it happens again.

Immediate actions (preserve evidence)

  • Make read-only copies of the current webroot and of the overwritten files you already saved. Record exact timestamps and where each copy came from.
  • Export the Version Control history for the project (the VCS keeps records of who did Gets/Restores). Keep a copy of the server Security event log covering the incident window. Do not clear or overwrite those logs.
  • If you suspect ongoing changes, temporarily revoke or disable any accounts that can write to the site until you have a controlled recovery plan.

Technical controls to prevent recurrence

  • Use NTFS permissions so only a single deploy/service account can write to the webroot. No one should edit production files directly from their desktop.
  • Move deploys to a controlled pipeline (scripts/CI) so commits to source control are the only way to change production; the pipeline uses the deploy account.
  • Limit VCS restore/checkout rights to the fewest necessary people. If you must use an old tool like SourceSafe, enforce strict user accounts and auditing; consider migrating to a modern VCS with better access controls and auditability.

Auditing and monitoring

  • Turn on object-access auditing for the webroot (targeted for write/modify/delete) but scope it to specific users or a short trial window to avoid log noise. Make sure Security log size and retention are configured and that logs are archived centrally.

Process and governance

  • Document a change control process: approvals, scheduled deploy windows, and an offboarding checklist that removes VCS and server access immediately when people change roles.
  • If you plan to escalate the incident, present a timeline (files, timestamps, VCS history, security logs) rather than speculation.

Thanks to for the log angle and for the audit suggestion — both directions are worth combining into the controls above.

Recommended Answers

All 6 Replies

If the log files have been properly configured, you should be able to find the info:

See also:

I've made a zillion mistakes, and this is one of them, so I'd assume this was my own error.
If not, it seems to me you need to make some security changes.

I just checked the IIS logs but it does not tell me anything related to the files modification.

This question is equivalent to if I replace a file on my co-worker's PC, can he find out who did it?

I have also looked at the server security log but that log tells me *anyone* who was trying to access the web site. I did do a test where I uploaded a file to the server, the security log shows my PC name and it logs me in 6 consecutive entries. I tried to find the if there are similar 6 entries near the time of the event and I cannot find similar entries

A genuine mystery-I think I'd feel compelled to figure it out, but it sounds as though no harm was done.
You might try posting in the web forum, where you'll find people who know a lot more than I do.

Just found out what really happened, if anyone interested:

Our former Web person, currently an Application Analyst, went in the Microsoft SourceSafe and restore the old files, when the SourceSafe asked her if she wanted to Replace current files, an option which is not selected by default, she hit that option. She is also one of the very few people who has access to the SourceSafe folder, being an Web guy, I don't even have the rights.

Intentional? I am about 99% sure she did it on purpose. I wonder if I should report her, I can't go to my manager because in on of my analyzed possible scenarios I put my boss behind all this.

Hard to say. I do problem solving. not politics.
If you're officially in charge, you should at least document the events.
I'd report it and make sure her credentials were revoked, which should be done as a routine precaution anyway.
I read an article recently that said disgruntled employees are responsible for some very high percentage of such events.
Good luck.

how about setting an audit on the wwwroot directory?

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.