Why Identity Threat Protection Starts with Detecting Phishing URLs
August 6, 2026The Four Minutes That Turned a Phishing Email Into a Microsoft 365 Account Compromise
August 14, 2026
The Login That Looked Normal: Investigating a Manufacturing Company Compromise
Incident Type: Suspected Endpoint Compromise
Environment: Windows enterprise network
Industry: Manufacturing
Initial Indicator: Employee-reported unusual login
Investigation Status: Confirmed compromise
The Incident
At 09:41 AM, an employee at a manufacturing company reported an unusual login notification associated with their corporate account.
The login itself did not immediately trigger a high-severity security alert.
The account was valid.
The authentication was successful.
No malware alert had been generated.
At first glance, it looked like a potentially legitimate login from an unfamiliar location.
The SOC team decided to investigate the endpoint associated with the account.
What they found changed the severity of the incident.
The First Clue: An Unusual Login
The authentication logs showed a successful login from an IP address that was not commonly associated with the employee.
A simplified version of the event looked like this:
09:41:22 LOGIN SUCCESS
User: employee01
Source IP: 185.xxx.xxx.xxx
Device: WIN-MFG-042
Status: SUCCESS
There was nothing inherently malicious about a successful authentication.
However, three things stood out:
- The source location was unusual for the employee.
- The login occurred outside the employee’s normal working pattern.
- The same endpoint generated additional security events shortly afterward.
The SOC analyst moved from the identity logs to endpoint telemetry.
That produced the first significant finding.
Evidence #1: Suspicious PowerShell Execution
Approximately one minute after the successful login, the endpoint executed PowerShell.
09:42:03 powershell.exe
09:42:05 Process created by WINWORD.EXE
09:42:07 Encoded command observed
PowerShell itself is not malicious.
It is widely used by administrators, automation systems, and legitimate enterprise applications.
The concern was the execution context.
The PowerShell process was launched unexpectedly and used an encoded command.
A simplified process relationship looked like:
WINWORD.EXE
|
└── powershell.exe
|
└── Encoded Command
This changed the investigation.
The SOC now had a possible sequence:
Successful authentication → suspicious process execution
The team began examining what PowerShell had executed and what happened immediately afterward.
Evidence #2: A New Administrator Account
The next finding was significantly more concerning.
At 09:48 AM, Windows recorded the creation of a new local account.
09:48:31 User account created
Username: svc_backup2
09:48:35 Account added to:
BUILTIN\Administrators
There was no corresponding change request or approved administrative activity.
The account name was also designed to resemble a legitimate service account.
This is a common investigation pattern:
An attacker who obtains an initial foothold may attempt to create or modify accounts to maintain privileged access.
The timeline was now becoming clearer:
09:41 Unusual authentication
↓
09:42 PowerShell execution
↓
09:48 New administrator account
The SOC began treating the incident as an active compromise rather than an isolated suspicious login.
Evidence #3: Outbound Traffic to Unknown Infrastructure
The investigation then moved to network telemetry.
At approximately 10:02 AM, the compromised workstation established repeated outbound connections to an external host that had not previously been associated with the organization’s normal business activity.
10:02:14
WIN-MFG-042
↓
External Infrastructure
TCP/443
↓
Large outbound data transfer
HTTPS traffic alone is not suspicious.
Modern applications generate enormous amounts of encrypted outbound traffic.
The important indicators were:
- The destination was previously unknown to the organization.
- The connections began after the suspicious PowerShell activity.
- The endpoint generated an unusually large outbound transfer.
- The traffic coincided with file-access activity on the workstation.
The SOC reviewed the process responsible for the network connection and found that the activity was associated with the same compromised endpoint.
At this stage, the investigation shifted toward a possible data theft scenario.
Evidence #4: Windows Event Logs Were Cleared
Then came the strongest indicator of deliberate attacker activity.
At 10:17 AM, Windows recorded an event indicating that the Security event log had been cleared.
10:17:44
Windows Security Event Log
Action: CLEAR
Host: WIN-MFG-042
Log deletion does not automatically prove an attack.
Administrators may legitimately clear logs during troubleshooting or maintenance.
But in this case, the sequence was difficult to ignore:
Unusual login
↓
PowerShell execution
↓
Administrator account creation
↓
Suspicious outbound traffic
↓
Security logs cleared
The SOC now had multiple independent indicators pointing toward the same conclusion.
Someone had obtained access to the workstation, executed commands, established privileged access, communicated with external infrastructure, and then attempted to reduce the available forensic evidence.
Reconstructing the Attack
With the evidence correlated across identity, endpoint and network telemetry, the SOC reconstructed the probable attack chain.
Compromised Employee Credentials
↓
Successful Login
↓
PowerShell Execution
↓
Privilege Escalation
↓
Administrator Account
↓
Internal Discovery
↓
Data Collection
↓
Outbound Data Transfer
↓
Log Destruction
The initial login was therefore not an isolated authentication anomaly.
It was the beginning of an endpoint compromise.
What Was the Attacker Trying to Achieve?
The available evidence suggests three primary objectives.
- Establish Access
The attacker first obtained access through a legitimate employee account.
Using valid credentials can be particularly difficult to detect because the authentication itself may appear legitimate.
- Establish Privileged Access
The creation of a new administrator account provided a potential persistence and privilege mechanism.
Even if the original compromised credentials were later disabled, the newly created account could potentially provide another route back into the system.
- Remove or Exfiltrate Data
The outbound traffic suggests that data may have been transferred from the compromised endpoint.
The subsequent clearing of Windows logs is consistent with an attempt to make investigation more difficult.
However, network traffic alone does not prove exactly what information was stolen. Investigators would need to correlate the transfer with file-access telemetry, endpoint artifacts and network logs before confirming data exfiltration.
MITRE ATT&CK Mapping
The observed activity can be mapped to several MITRE ATT&CK techniques based on the evidence collected during the investigation.
| Observed Activity | MITRE ATT&CK Technique | Relevance |
|---|---|---|
| Compromised employee credentials used for authentication | T1078 — Valid Accounts | The attacker appears to have accessed the environment using legitimate account credentials. |
| Suspicious PowerShell execution | T1059.001 — PowerShell | PowerShell was used to execute commands on the compromised Windows endpoint. |
| Creation of a new administrator account | T1136 — Create Account | The attacker created an additional account that was subsequently granted administrative privileges. |
| Security event logs cleared | T1070.001 — Clear Windows Event Logs | Clearing Windows logs may have been used to remove evidence of malicious activity. |
| Suspicious outbound data transfer | T1041 — Exfiltration Over C2 Channel (potential) | The outbound transfer may represent data exfiltration if further investigation confirms that the traffic used an attacker-controlled command-and-control channel. |
The mapping should remain evidence-driven. A technique should not be assigned simply because it could have been used; investigators should correlate the technique with endpoint, identity and network telemetry before treating it as confirmed.
Attack Chain at a Glance
T1078
Valid Accounts
↓
T1059.001
PowerShell
↓
T1136
Create Account
↓
Data Collection / Transfer
↓
T1041
Potential Exfiltration
↓
T1070.001
Clear Windows Event Logs
This sequence demonstrates how an apparently legitimate authentication event can evolve into a multi-stage compromise when identity, endpoint and network activity are correlated.
Where Could the Attack Have Been Detected Earlier?
The incident demonstrates why looking at individual alerts can be insufficient.
Consider each event independently:
Successful login
→ Could be legitimate.
PowerShell
→ Could be legitimate administration.
New administrator account
→ Could be a maintenance task.
HTTPS traffic
→ Could be normal.
Cleared event logs
→ Could be administrative activity.
But when correlated together:
Unusual Login
+
Suspicious PowerShell
+
Unexpected Admin Account
+
Unknown External Destination
+
Log Clearing
=
High-Confidence Security Incident
This is where security monitoring becomes much more valuable than isolated alert generation.
What the SOC Should Do Next
Once the compromise is suspected, the priority should be containment while preserving evidence.
Immediate containment
- Disable or isolate the compromised account.
- Isolate the affected endpoint from the network.
- Disable the unauthorized administrator account.
- Revoke active authentication sessions.
- Reset potentially compromised credentials.
- Block confirmed malicious infrastructure.
Investigation
The SOC should then examine:
- PowerShell command history
- Windows Event Logs
- EDR process trees
- Authentication records
- Network connections
- Recently accessed files
- Newly created accounts
- Scheduled tasks
- Registry modifications
- Browser credentials and sessions
- Other endpoints accessed by the compromised account
The investigation should also determine whether the attacker moved laterally to other systems.
The Bigger Lesson
The most important lesson from this incident is not that PowerShell is dangerous.
It isn’t.
Nor does an unusual login automatically mean an account has been compromised.
The problem was the combination of otherwise explainable events.
The attacker potentially moved through several layers:
Identity → Endpoint → Privilege → Network → Data
A security team monitoring only one of those layers could easily miss the larger attack.
For example, an identity system may see a legitimate login.
An endpoint security platform may see PowerShell.
A network monitoring system may see encrypted HTTPS traffic.
A Windows administrator may see a new account.
The attack becomes much clearer when these signals are correlated.
Key Takeaways for Security Teams
- Investigate authentication anomalies in context.
A successful login is not necessarily benign. Location, device, timing and subsequent activity matter.
- Monitor PowerShell behavior, not simply PowerShell execution.
Parent process, command-line arguments, encoding and execution context can provide important signals.
- Alert on unexpected privileged account creation.
New administrator accounts should have a clear business or operational reason.
- Monitor unusual outbound behavior.
Unknown destinations combined with abnormal data transfer should trigger investigation.
- Protect security logs from tampering.
Attackers understand that logs are valuable evidence. Log forwarding to a centralized and protected platform can make local log deletion less effective.
- Correlate identity, endpoint and network telemetry.
No single event necessarily proves compromise. The sequence often tells the story.
How Securiglobe Can Help
Incidents like this demonstrate why cybersecurity cannot depend on a single defensive layer.
Securiglobe’s security services can help organizations identify weaknesses across different stages of the attack lifecycle, including VAPT, network security assessment, incident response, digital forensics, Active Directory security, cloud security assessment and cybersecurity maturity assessment.
For organizations concerned about phishing and credential-based attacks, Securiglobe’s RIEG phishing protection platform can also help identify and protect users from malicious links and phishing-driven attacks before they become an identity compromise.
The objective is not simply to generate more alerts.
It is to identify suspicious activity early, understand how an attacker could move through the environment, and reduce the opportunity for a minor compromise to become a major incident.
Final Takeaway
The investigation began with a simple employee report:
“I received an unusual login notification.”
What initially looked like an authentication anomaly eventually revealed a much larger sequence of events:
Valid account → PowerShell → Privileged account → External communication → Log deletion
That is why effective incident investigation requires more than looking for a single malicious event.
The attack is often hidden in the sequence.
