OS and account basics in security for new analysts

Why OS structure matters for security work

When you analyze security alerts, you constantly see file paths, processes and services. If you do not know how an operating system is structured, those details look like random text. You want to recognize what runs at startup, where programs live and where user data is stored. This helps you tell normal activity from suspicious behavior. For example, seeing a browser in Program Files is fine, seeing it start from a temp folder is a red flag. Start with one OS you use daily, usually Windows, and learn its basic folders, services and startup locations. That knowledge transfers to macOS and Linux later.

Key Windows folders and what they mean in logs

Most entry level security alerts involve Windows. Learn the common folders that appear in telemetry. C:\Windows and C:\Program Files usually hold system and installed software. C:\Users holds user profiles, including Desktop, Documents and Downloads. Temp and AppData paths are often abused by malware because users write there. When you see a process or script starting from an odd folder, pause. Ask if a normal user or trusted installer would use that location. In a home lab, open Task Manager, pick a process, right click and view its file location. Then compare that to how it appears in Windows Event Logs.

Account types and why attackers love admin rights

To read alerts correctly, you must understand account types. Standard user accounts should have limited permissions. Local administrator or domain administrator accounts can install software, change settings and access more data. Attackers try to steal powerful accounts so they can move across systems without constant obstacles. When you see a risky action in logs, always note which account performed it. Was it a normal user, a local admin or a service account. A good habit for any analyst is to assume every high privilege action is suspicious until you can explain it with a real business need.

Local, domain and service accounts in real alerts

Different account scopes show up differently in telemetry. A local account exists only on that machine. A domain account is managed by Active Directory and can sign in to many systems. Service accounts run applications or scheduled tasks. When you review an alert, identify the account type from its name and context. For example, DOMAIN\j.smith is likely a user, DOMAIN\sqlservice is likely a service account. Unusual sign ins or commands from a service account are big red flags. In your lab, create a local user and a simple scheduled task, then see how each one appears in Event Viewer.

First practical steps to connect OS and accounts with logs

You do not need a huge lab to start building intuition. Use your existing computer and practice connecting what you do with what appears in logs. Create a test user without admin rights. Log in, create folders and run a browser, then open Event Viewer or system logs and look for those actions. Next, enable logging for PowerShell and process creation if possible and run a few simple commands. Notice which account is recorded, which path is used and which process name appears. This habit trains you to read alerts like a story instead of isolated technical fields.

Useful links

• Microsoft Windows security documentation — Official documentation for Windows security, accounts and logging.
• Linux project homepage — Starting point for understanding Linux kernels and distributions.

Keep learning