With regards to the Access Log, Unwired suggests that this is fairly standard for hackers: "A good hacker will always perform a Data Search through the file and then an Edit to remove any trace of her presence." Makes sense, since if you leave any entries in the Access Log, they can run a Trace on you after the fact.

However "For all Matrix actions performed in a node, records are created." So you perform your data search, and you perform your edit, removing any entries for ID1138, but then as you complete those actions, two new entries get appended to the log:
26JUN2071-19:03:38>ID1138 performed data search on file access.log
26JUN2071-19:03:41>ID1138 performed edit on file access.log

So, aside from letting the edit utility change an entry that hasn't been made yet, what's the solution to this one? Even logging back in via a hidden access point, which obscures and confuses the entries because they're not associated with any account still explicitly allows for a Trace to be performed from undeleted entries in the Access Log. Best I can think is a virus specifically crafted to delete those entries the next time someone reads the file, injected directly into the Access Log just prior to logout. And hope they don't run a purge on the Access Log before reading it.

Node script the search and edit to execute next time a user leaves, tack on the destruction of the node script itself as well. Then you leave and the node script wipes your presence behind you.

I knew I was missing something simple. SUDO delete my traces. (And make me a a sandwich.)

That or spawn a daemon on the node (not to failure with the sr term for it), have it remove your traces then itself after a set amount of time, or prompting through a back door or something. the logs would contain records of what the daemon did, so its close.

that or, simply formate the entire node that would totally remove your tracks

Well, in the real world this is kind of the case. It's not uncommon for the act of editing logs to be more noticeable than whatever act was recorded by the logs. I've got friends who do computer forensics for a Fortune 100 and more than a few people were caught when their attempts to clean a log triggered an alert. In a busy network, a period with no logs is more glaring an issue than hinky activity.

If you've acquired an actual user account, it's pretty easy since you just need to edit the log entries where you accessed the paydata to something the user account normally touches. As long as you stay in the user-account's normal activity zone, it's very hard to detect.

The thing to remember is that if you don't trigger an alert, the data log must not be weird enough to be an obvious issue. I mean, if the logs really said "01:13 - User:IStealYourStuff File_Read:Paydata.PDF (Permission Restrictions Ignored)" don't you think the node's ICE would kick in immediately?

Your Stealth will ensure the logs say something like "01:13 - Service:AVClient File_Read:Paydata.PDF." Of course, that still shows that Paydata.PDF was accessed. If someone later does a breakdown on every time Paydata.PDF was accessed, they might find something you did in that timeframe that leads back to your IP address so you'll want to change that log to "01:13 - User:AVClient File_Read:TimmysXmasList.txt". Then the worst that they'll find is the logs show "01:14 - User:AVClient File_Edit:System.log".

That is something of a fingerprint but it's sufficiently low-key that it would require a later investigation with more processing power than the node's active defenses to detect your activities. Really, the biggest risk to a hacker who gets in and out without an alert is that some other hacker will trigger an alert in the next couple of days causing all the logs to be audited.

I don't think you need to use agents or write a node script to clear your tracks after you leave. It says that the access log doesn't get written for System turns after the loggable actions (includes everything except log out) have been done. Until then, the data is stored in a raw format by the node.

The implication I got was that the search and edit functions not only edit out previous actions in the written access log, but also edit the raw log data that hasn't been written yet, which means it covers your tracks as long as you do nothing else before logging out.

I could be wrong though.

One company I know uses a DAT tape that writes every command issued to the server, you have to physically take out the DAT tape to rewind it.

Of course, even before it's written to the server, it has to exist in memory - editing it there would be the trick.

And realize that this is Unwired - you're processing, storing and sending hundreds of terabytes of information per second just to generate the simsense feed, nevermind the actual commands. So it's likely that permanent WORM-style storage just isn't fast enough, and has to be cached and buffered. So you just edit it while it's still in the buffer.

Many companies use a log server that is sent every event notice by all the machines. Paranoid places use two servers; one accessible on the LAN for general system analysis and one hooked up with one-way cables that is otherwise not on-net and essentially immune to hacking. These often have an outbound-only connection that they can scream down when incoming logs stop.

Now, event notices are really up to the application author, however the operating system can initiate event notices for core OS tasks (file read, write, execute, etc) and a really secure OS won't complete a task until the event notice is logged. This doesn't prevent a hack since the syslog daemon can be hacked to send bogus data to the log server or to give false acknowledgements of logging to the OS, however the hacker can never erase the log entry for modifying syslog daemon since that action will be logged before the modification takes place..

In the real world, that's almost impossible to hide from a follow up forensics tear down. In Shadowrun, one would assume that the hacker's Stealth application would somehow obfuscate the message so that it isn't obvious that the syslog daemon was hacked, or at least that it wasn't modified by a daemon or user that would otherwise have the rights to do so.