Windows Event Log, Logon and Logoff

A subject with access to a billing system or indirect access to a billing system misuses their access to create fraudulent invoices, causing payments to be diverted to themselves, a business they own, or a third party.

The subject intentionally weakens or bypasses network security controls for a third party, such as providing credentials or disabling security controls.

A subject deliberately shares credentials for non-personal, persistent service accounts (e.g., admin, automation, deployment) with other individuals, either within or outside their team. These accounts often lack individual attribution, and when shared, they create a pool of untracked, unaccountable access.

Service account sharing typically emerges in high-pressure operational environments where speed or convenience is prioritized over access hygiene. Teams may rationalize the behavior as necessary to meet deployment deadlines, maintain uptime, or circumvent perceived access bottlenecks. In other cases, access may be extended informally to external collaborators, such as contractors or partner engineers, without proper onboarding or oversight.

When service account credentials are distributed, they become functionally equivalent to a shared key—undermining all identity-based controls. Investigators lose the ability to reliably associate actions with individuals, making forensic attribution difficult or impossible. This gap often delays incident response and enables repeated policy violations without detection.

Service accounts also frequently carry elevated privileges, operate without MFA, and are excluded from normal UAM logging, compounding the risk. Their use in this manner represents not just a technical misstep, but a structural breakdown in control integrity and accountability. In environments with compliance obligations or segmented access controls, service account sharing is a critical investigative red flag and should trigger formal review.

The subject deploys a Remote Access Tool (RAT): a software implant that provides covert, persistent remote control of an endpoint or server—enabling continued unauthorized access, monitoring, or post-employment re-entry. Unlike sanctioned remote administration platforms, RATs are deployed without organizational oversight and are often configured to obfuscate their presence, evade detection, or blend into legitimate activity.

RATs deployed by insiders may be off-the-shelf tools (e.g. njRAT, Quasar, Remcos), lightly modified open-source frameworks (e.g. Havoc, Pupy), or commercial-grade products repurposed for unsanctioned use (e.g. AnyDesk, TeamViewer in stealth mode). 

Functionality typically includes:

• Full GUI or shell access
• File system interaction
• Screenshot and webcam capture
• Credential harvesting
• Process and registry manipulation
• Optional keylogging and persistence modules

Deployment methods include manual installation, script-wrapped droppers, DLL side-loading, or execution via LOLBins (mshta, rundll32). Persistence is typically achieved through scheduled tasks, registry run keys, or disguised service installations. In some cases, the RAT may be configured to activate only during specific windows or respond to remote beacons, reducing exposure to detection.

A subject deliberately shares credentials for an individually assigned user account with another person, or uses credentials assigned to another individual without authorization. Individually assigned accounts are intended to be used only by the assigned account holder and are governed by organizational policy, access control requirements, and identity management processes. Sharing or using another person’s account violates these controls by moving access outside approved provisioning, delegation, and review mechanisms.

User account sharing typically emerges where convenience, workload pressure, informal delegation, or perceived access delays are prioritized over account-use policy. Teams may rationalize the behavior as necessary for shift coverage, urgent operational tasks, peer assistance, or temporary access needs. In other cases, a subject may share or receive account credentials to avoid onboarding delays, bypass access request processes, or complete work without obtaining the permissions formally required for their role.

When user account credentials are shared, the receiving individual gains access through an identity that was not assigned, approved, or reviewed for their use. This can bypass role-based access controls, segregation of duties, conditional access policies, approval workflows, and access review assumptions. The infringement is not dependent on malicious intent; the policy violation arises from the unauthorized transfer or use of identity-bound access.

User account sharing may expose sensitive systems, regulated data, approval functions, administrative consoles, or business workflows to individuals who have not been formally authorized for that level of access. In environments with compliance obligations, privileged workflows, or strict access governance requirements, user account sharing should be treated as a significant infringement and reviewed against the organization’s Acceptable Use Policy, identity governance standards, and disciplinary or remediation processes.