Making this post so that all of you get an idea on exactly how is a life of a Threat Analyst(MDR) and what are my D2D activity.

6:30 AM. Swim first, before my brain fully gets activated. Best decision I've made this year. Relaxes the mind.

8:15. Coffee. Non negotiable. I've tried skipping it twice. Both days ended badly(consider it as a superstition or the screen effect).

9:30, I log in. WFH, so I just need to walk from the kitchen to my desk. First thing I check isn't the XDR portal, it's email, calendar, Slack, and Teams, in that order, because half the time overnight shift has already flagged something for me and I don't want to walk into a case cold.

10:00 onward is when it actually starts. Into the XDR portal, sorting through alerts and detections that queued. MDR is a 24/7 job. Some days it's quiet. Some days I open the queue and immediately know it's going to be a long one, usually because three alerts from the same host are all pointing the same direction.

The investigation part is where time flies or disappears. Querying event logs, pulling process trees, checking parent child relationships, cross referencing against what the endpoint saw versus what the network saw. Verifying the Threat Intel. I've lost entire hours to a single suspicious PowerShell execution that turned out to be an IT admin running a script nobody informed us or documented anywhere.

Around midday, at around 1 or 2, I usually get on a call with a client if something needs explaining in technical POV. That's a different skill entirely. You can be great at reading a process tree and still fumble explaining it to someone who just wants to know if their business is on fire. I learnt it a hard way, don't want you guys to struggle on that aspect.

Response actions, if needed, isolating a host, killing a process, blocking an IOC. Then lunch, which I try to actually eat away from the screen, or watch some Sit Coms.

Afternoon is round two of the same loop. New alerts, new queries, sometimes picking back up a case from the morning that needed more eyes in investigation.

The fun part nobody tells you about this job is that you start recognizing patterns in things that have nothing to do with the job. Once this job gets into your head, it doesn't fully leave.

End of day is a wrap up meeting, log off, and then TV and sleep, trying not to think about tomorrow's queue.

If you're planning to go for SOC or threat analysis in near future, this is a glimpse of a day, which I am sure nobody told you about.

So this is another case study, where I break down actual detections/alerts which I investigate as a Threat Analyst. The event started with Event 4769: TGS request, but the timestamp looked off. Source was a host I didn't recognize(unmanaged in XDR), and it was asking for tickets on service accounts nobody should be doing so.

Now this attack would help you understand why Kerberos is both good and bad at the same time.

The flow for the attack is that attacker enumerates service accounts using GetUserSPNs or SharpHound. Then gets the SPNs. Then requests TGS tickets for those accounts without needing admin access. Events 4769 shows up as RC4 encryption (Event Code 0x17). If you miss this, it looks like normal Kerberos traffic. But...It's not.

Then attackers can take those tickets offline and crack the password. Once they have the service account password, they can logon (Event 4624) with explicit credentials (Event 4648, typing username/pass manually). This is where I caught mine. New service account logon from a source that had no usage being there, this was not a normal behaviour.

But thing is that by the time I found that, stuff got bad and attacker already escalated to a privileged account (4672), dumped credentials with Mimikatz, and now I was checking for lateral movement. I found process creation events (4688) for PowerView. They were enumerating shares. Then came the DCSync attempts (4662).

That's when I knew the domain was probably already theirs. And its time to take response actions fast.

I isolated the host, disabled the compromised accounts, reset service account passwords, and started hunting more afterwards. Turns out they'd already set up persistence with a golden ticket. The KRBTGT needed to be reset twice.

The reason I'm posting this is that most writeups show you the attack flow and the queries. They don't show you what it actually feels like when you're running these queries in real time, when you know something is wrong but you're not sure how deep it goes yet.

If you're studying for SOC or breaking into security, you need to see this happen live. Not in a lab. In real events, real queries, real pressure.

P.S: Thank you for loving my last case study on GTA 6. Appreciate your love!

So this is another case study, where I break down actual detections/alerts which I investigate as a Threat Analyst.

The event started with Event 4769: TGS request, but the timestamp looked off. Source was a host I didn't recognize(unmanaged in XDR), and it was asking for tickets on service accounts nobody should be doing so.

Now this attack would help you understand why Kerberos is both good and bad at the same time.

The flow for the attack is that attacker enumerates service accounts using GetUserSPNs or SharpHound. Then gets the SPNs. Then requests TGS tickets for those accounts without needing admin access. Events 4769 shows up as RC4 encryption (Event Code 0x17). If you miss this, it looks like normal Kerberos traffic. But...It's not.

Then attackers can take those tickets offline and crack the password. Once they have the service account password, they can logon (Event 4624) with explicit credentials (Event 4648, typing username/pass manually). This is where I caught mine. New service account logon from a source that had no usage being there, this was not a normal behaviour.

But thing is that by the time I found that, stuff got bad and attacker already escalated to a privileged account (4672), dumped credentials with Mimikatz, and now I was checking for lateral movement. I found process creation events (4688) for PowerView. They were enumerating shares. Then came the DCSync attempts (4662).

That's when I knew the domain was probably already theirs. And its time to take response actions fast.

I isolated the host, disabled the compromised accounts, reset service account passwords, and started hunting more afterwards. Turns out they'd already set up persistence with a golden ticket. The KRBTGT needed to be reset twice.

The reason I'm posting this is that most writeups show you the attack flow and the queries. They don't show you what it actually feels like when you're running these queries in real time, when you know something is wrong but you're not sure how deep it goes yet.

If you're studying for SOC or breaking into security, you need to see this happen live. Not in a lab. In real events, real queries, real pressure.

P.S: Thank you for loving my last case study on GTA 6. Appreciate your love!

Real Life Case Example Part 2:

Just caught something wild at work yesterday. GTA 6 is gonna launch sometime soon, but one our client wanted early access.

A user (Ryan) downloaded what looked like a "free GTA 6 crack" from firefox, file was named "GTA6_Setup_Crack_2026.exe", unsigned, 84.7 MB. Executed it at 10:13 AM. The next 3 minutes were brutal. The installer spawned PowerShell with hidden windows, dropped an unsigned binary (vcruntime_update.exe) into AppData, created a registry Run key named "RockstarGameUpdater", and set up a scheduled task for persistence on login.

Then it got worse, vcruntime_update.exe went straight for the browser credential stores. Chrome login data, Edge login data, Firefox logins.json, all accessed within seconds. Created a ZIP archive in Temp (syscache_4931.zip) and attempted a 2.3 MB upload to panelgtasupport[.]top on port 8080 before we blocked it.

DNS queries to four suspicious domains, all gaming themed: cdnrockstarupdate[.]com, apigta6launcher[.]xyz, panelgtasupport[.]top, rawcdngamepatch[.]site. All resolved to infrastructure that basically were C2.

Timeline from execution to EDR kill: 3 minutes, 57 seconds.

This is textbook infostealer and RAT behavior delivered through a game crack. The naming masquerade (RockstarGameUpdater, vcruntime_update) is it. The browser credential access is the payload. The persistence ensures it survives a reboot.

For anyone job hunting in SOC, this is exactly the kind of chain you need to recognize in 30 seconds during a real investigation. The red flags stack, unsigned binary, masqueraded process names, AppData execution, browser credential access, suspicious domains, persistence setup.

Any of you seen similar patterns? How do you typically investigate these in your environments?

Also, thinking of writing a blog on it on Medium soon, with proper process tree, file details, running process observation and activity timeline stuff.

Real Life Case Example Part 2:

Thank you for giving so much love on my previous post, I am thinking of starting a weekly series where I breakdown real case studies which I solve at work as a Threat Analyst.

Just caught something wild at work yesterday. GTA 6 is gonna launch sometime soon, but one our client wanted early access.

A user (Ryan) downloaded what looked like a "free GTA 6 crack" from firefox, file was named "GTA6_Setup_Crack_2026.exe", unsigned, 84.7 MB. Executed it at 10:13 AM. The next 3 minutes were brutal. The installer spawned PowerShell with hidden windows, dropped an unsigned binary (vcruntime_update.exe) into AppData, created a registry Run key named "RockstarGameUpdater", and set up a scheduled task for persistence on login.

Then it got worse, vcruntime_update.exe went straight for the browser credential stores. Chrome login data, Edge login data, Firefox logins.json, all accessed within seconds. Created a ZIP archive in Temp (syscache_4931.zip) and attempted a 2.3 MB upload to panelgtasupport[.]top on port 8080 before we blocked it.

DNS queries to four suspicious domains, all gaming themed: cdnrockstarupdate[.]com, apigta6launcher[.]xyz, panelgtasupport[.]top, rawcdngamepatch[.]site. All resolved to infrastructure that basically were C2.

Timeline from execution to EDR kill: 3 minutes, 57 seconds.

This is textbook infostealer and RAT behavior delivered through a game crack. The naming masquerade (RockstarGameUpdater, vcruntime_update) is it. The browser credential access is the payload. The persistence ensures it survives a reboot.

For anyone job hunting in SOC, this is exactly the kind of chain you need to recognize in 30 seconds during a real investigation. The red flags stack, unsigned binary, masqueraded process names, AppData execution, browser credential access, suspicious domains, persistence setup.

Any of you seen similar patterns? How do you typically investigate these in your environments?

Also, thinking of writing a blog on it on Medium soon, with proper process tree, file details, running process observation and activity timeline stuff.

Just caught something wild at work yesterday. GTA 6 is gonna launch sometime soon, but one our client wanted early access.

A user (Ryan) downloaded what looked like a "free GTA 6 crack" from firefox, file was named "GTA6_Setup_Crack_2026.exe", unsigned, 84.7 MB. Executed it at 10:13 AM. The next 3 minutes were brutal. The installer spawned PowerShell with hidden windows, dropped an unsigned binary (vcruntime_update.exe) into AppData, created a registry Run key named "RockstarGameUpdater", and set up a scheduled task for persistence on login.

Then it got worse, vcruntime_update.exe went straight for the browser credential stores. Chrome login data, Edge login data, Firefox logins.json, all accessed within seconds. Created a ZIP archive in Temp (syscache_4931.zip) and attempted a 2.3 MB upload to panelgtasupport[.]top on port 8080 before we blocked it.

DNS queries to four suspicious domains, all gaming themed: cdnrockstarupdate[.]com, apigta6launcher[.]xyz, panelgtasupport[.]top, rawcdngamepatch[.]site. All resolved to infrastructure that basically were C2.

Timeline from execution to EDR kill: 3 minutes, 57 seconds.

This is textbook infostealer and RAT behavior delivered through a game crack. The naming masquerade (RockstarGameUpdater, vcruntime_update) is it. The browser credential access is the payload. The persistence ensures it survives a reboot.

For anyone job hunting in SOC, this is exactly the kind of chain you need to recognize in 30 seconds during a real investigation. The red flags stack, unsigned binary, masqueraded process names, AppData execution, browser credential access, suspicious domains, persistence setup.

Any of you seen similar patterns? How do you typically investigate these in your environments?

Also, thinking of writing a blog on it on Medium soon, with proper process tree, file details, running process observation and activity timeline stuff.

Wanted to drop this here because I've seen a lot of posts asking how to investigate alerts that look normal/benign so let me share a real case from a few days back at my work.

Warning: long post. Lots of detail. I think it'll change how you look at identity alerts. But worth it if you're learning security work.

--------------------------------------------------------------------------------------------------------------

Few days back, after lunch, I get an alert. Azure AD, suspicious login. I almost scrolled past it.

No malware. No exploit. Just a login that succeeded.

Alert/Detection Raw Data (Changed from actual data, for obvious privacy reasons):

Timestamp: 2026-06-19 02:11:07
User: rahul.sharma@company.com
Result: SUCCESS
Source IP: 185.234.72.91
Location: Romania
Device: Windows 10 (Unknown)
Application: Exchange Online
MFA: Passed

Now on the surface, nothing here screams incident/malicious. It's a successful login. MFA passed. System says everything's fine.

But something felt wrong(can say it gut feeling after dealing with 100s of detections), so I kept going.

--------------------------------------------------------------------------------------------------------------

First thing I always do: baseline the user

Before I call anything suspicious, I pull 30 days of login history for that account. Takes 2 minutes, saves you from false positives and helps you build a real case if it is malicious.

This user, Rahul, in this case, always logged in from Bangalore. MacBook. Corporate VPN. 9 AM to 7 PM window. Every single day for 30 days.

Current login: Romania. Unknown Windows machine. 2 AM. No VPN.

Zero overlap. Not a single normal parameter matched.

That's when I stopped treating it as suspicious and started treating it as a compromise.

--------------------------------------------------------------------------------------------------------------

Then I reconstructed the full timeline

This is the part most people skip and it's the most important thing you can do. Pull SIEM + M365 logs together and build out exactly what happened, minute by minute.

This is what I found(actual logs don't look like this, below is a simplified version):

02:09:11 → Failed login
02:09:40 → Failed login  
02:10:02 → Failed login
02:11:07 → SUCCESS

02:12:30 → Accessed Exchange mailbox
02:14:10 → Created inbox rule: forward all emails to external address
02:18:54 → Logged into SharePoint
02:22:11 → Downloaded 3 files (~25 MB)
02:25:40 → Second login, same IP
02:30:02 → OAuth app consent granted

Three failures then a clean success. And then 18 minutes of very specific, deliberate actions.

Real users don't behave like this. Real users open their email, check something, close it. They don't create forwarding rules and download files at 2 in the morning within 10 minutes of logging in.

This is what attackers look like when they get in. They already know what they want and they move fast.

--------------------------------------------------------------------------------------------------------------

The MFA thing and this is what most people don't understand

MFA passed. I called the user. He said he had no idea what I was talking about, didn't approve any prompt, was asleep.

So how does MFA pass without the user?

There are two ways this happens and both are common enough that you'll see them if you work in MDR/SOC long enough.

AiTM phishing: the attacker sets up a reverse proxy site that looks exactly like the real login page. User gets a phishing link, goes to the fake page, enters their credentials. The proxy forwards everything to Microsoft in real time. Microsoft sends MFA to the user's phone. User approves it thinking it's normal. But the attacker's proxy captures the authenticated session token before the user gets redirected to the real dashboard. Now the attacker has a valid, MFA authenticated session token. They don't need the password anymore.

Token replay: attacker already had a session token from an older compromise or cookie theft. Token wasn't expired yet. No new MFA challenge triggered at all.

Either way, this is the thing to understand. MFA protects your password. It does not protect your session. Once an attacker has a valid session token, MFA has already done its job from the system's perspective. You're logged in.

--------------------------------------------------------------------------------------------------------------

The IP Part, hardly takes 10 sec, but tells you a lot

"185[.]234[.]xx[.]xx"(pro tip: always defang the IP/URL) ran it through a couple of threat intel sources. Hosted on a cloud provider, not a residential ISP. Flagged as suspicious across multiple feeds.

Normal users don't log in from hosting providers at 2 AM. That's either a VPS someone rented or a compromised server being used as a jump point.

--------------------------------------------------------------------------------------------------------------

Post-login activity is what actually confirmed the compromise

The login itself is suspicious. What happened after is what closes the case.

Inbox forwarding rule attacker set up silent forwarding to an external address. Every email Rahul receives from now on also goes to the attacker. Even after you kick them out, if you miss this rule, they keep reading his email.

File downloads SharePoint, 3 files, 25 MB. Whatever those files contained, the attacker has them now.

OAuth app consent this is the sneaky one. The attacker added an OAuth application to the account. OAuth tokens survive password resets. So if you reset Rahul's password and don't specifically check and revoke OAuth app permissions, the attacker still has access. I've seen this catch incident responders off guard more than once.

--------------------------------------------------------------------------------------------------------------

Why this is harder to catch than malware

This attack maps to MITRE ATT&CK T1078 Valid Accounts. No payload. No exploit. No EDR alert. Everything the attacker did was technically legitimate from the system's perspective because they were operating inside a real, authenticated session.

Your SIEM has no way to distinguish "Rahul downloaded files" from "attacker using Rahul's session downloaded files" without behavioral context. That's why the baseline matters. That's why timeline reconstruction matters.

The attacker didn't break in. They logged in.

--------------------------------------------------------------------------------------------------------------

What I would have faced if I delayed this by even few minutes

The inbox forwarding rule was already running. Every email coming into that account was silently copying to an attacker controlled address. If Rahul was CC'd on anything sensitive in the next few hours be it project files, client data, internal announcements, it was ufff gone.

The OAuth app meant the attacker had a backdoor that survives a password reset. You could kick them out, reset everything, and they'd be back in quietly the next day through the app they already authorized.

And the internal email account thing is what actually scares me most. An email from rahul[.]sharma@company[.]com(Notice how I defang it) to another internal employee doesn't trigger the same suspicion as an external phishing email. Attacker could have used that account to phish colleagues, get someone else to click something, and then you have a second compromised account from a trusted internal sender.

That's how these escalate from one account to a full lateral compromise.

--------------------------------------------------------------------------------------------------------------

What I did to contain it(Response Actions Stuff)

Disabled the account immediately. Forced password reset. Killed all active sessions. Re-enrolled MFA fresh on a verified device.

Then the cleanup: removed the forwarding rule, revoked the OAuth app, reviewed 7 days of sent email history to check if the account had already been used to send anything malicious, forced sign-out across all tenants.

Called the customer, as mentioned earlier, walked them through what happened.

--------------------------------------------------------------------------------------------------------------

I'll add the KQL queries for pulling Azure AD sign in anomalies and inbox rule creation events if enough people want it, just say so in the comments and I'll do a follow-up.

--------------------------------------------------------------------------------------------------------------

Upvote and save this if you found it useful. Share it with someone prepping for SOC interviews, this is the kind of thinking that actually gets you hired.

Also, let me know what else do you want me to break down? Drop it in the comments.

Wanted to drop this here because I've seen a lot of posts asking how to investigate alerts that look normal/benign so let me share a real case from a few days back at my work.

Warning: long post. Lots of detail. I think it'll change how you look at identity alerts. But worth it if you're learning security work.

--------------------------------------------------------------------------------------------------------------

Few days back, after lunch, I get an alert. Azure AD, suspicious login. I almost scrolled past it.

No malware. No exploit. Just a login that succeeded.

Alert/Detection Raw Data (Changed from actual data, for obvious privacy reasons):

Timestamp: 2026-06-19 02:11:07
User: rahul.sharma@company.com
Result: SUCCESS
Source IP: 185.234.72.91
Location: Romania
Device: Windows 10 (Unknown)
Application: Exchange Online
MFA: Passed

Now on the surface, nothing here screams incident/malicious. It's a successful login. MFA passed. System says everything's fine.

But something felt wrong(can say it gut feeling after dealing with 100s of detections), so I kept going.

--------------------------------------------------------------------------------------------------------------

First thing I always do: baseline the user

Before I call anything suspicious, I pull 30 days of login history for that account. Takes 2 minutes, saves you from false positives and helps you build a real case if it is malicious.

This user, Rahul, in this case, always logged in from Bangalore. MacBook. Corporate VPN. 9 AM to 7 PM window. Every single day for 30 days.

Current login: Romania. Unknown Windows machine. 2 AM. No VPN.

Zero overlap. Not a single normal parameter matched.

That's when I stopped treating it as suspicious and started treating it as a compromise.

--------------------------------------------------------------------------------------------------------------

Then I reconstructed the full timeline

This is the part most people skip and it's the most important thing you can do. Pull SIEM + M365 logs together and build out exactly what happened, minute by minute.

This is what I found(actual logs don't look like this, below is a simplified version):

02:09:11 → Failed login
02:09:40 → Failed login  
02:10:02 → Failed login
02:11:07 → SUCCESS

02:12:30 → Accessed Exchange mailbox
02:14:10 → Created inbox rule: forward all emails to external address
02:18:54 → Logged into SharePoint
02:22:11 → Downloaded 3 files (~25 MB)
02:25:40 → Second login, same IP
02:30:02 → OAuth app consent granted

Three failures then a clean success. And then 18 minutes of very specific, deliberate actions.

Real users don't behave like this. Real users open their email, check something, close it. They don't create forwarding rules and download files at 2 in the morning within 10 minutes of logging in.

This is what attackers look like when they get in. They already know what they want and they move fast.

--------------------------------------------------------------------------------------------------------------

The MFA thing and this is what most people don't understand

MFA passed. I called the user. He said he had no idea what I was talking about, didn't approve any prompt, was asleep.

So how does MFA pass without the user?

There are two ways this happens and both are common enough that you'll see them if you work in MDR/SOC long enough.

AiTM phishing: the attacker sets up a reverse proxy site that looks exactly like the real login page. User gets a phishing link, goes to the fake page, enters their credentials. The proxy forwards everything to Microsoft in real time. Microsoft sends MFA to the user's phone. User approves it thinking it's normal. But the attacker's proxy captures the authenticated session token before the user gets redirected to the real dashboard. Now the attacker has a valid, MFA authenticated session token. They don't need the password anymore.

Token replay: attacker already had a session token from an older compromise or cookie theft. Token wasn't expired yet. No new MFA challenge triggered at all.

Either way, this is the thing to understand. MFA protects your password. It does not protect your session. Once an attacker has a valid session token, MFA has already done its job from the system's perspective. You're logged in.

--------------------------------------------------------------------------------------------------------------

The IP Part, hardly takes 10 sec, but tells you a lot

"185[.]234[.]xx[.]xx"(pro tip: always defang the IP/URL) ran it through a couple of threat intel sources. Hosted on a cloud provider, not a residential ISP. Flagged as suspicious across multiple feeds.

Normal users don't log in from hosting providers at 2 AM. That's either a VPS someone rented or a compromised server being used as a jump point.

--------------------------------------------------------------------------------------------------------------

Post-login activity is what actually confirmed the compromise

The login itself is suspicious. What happened after is what closes the case.

Inbox forwarding rule attacker set up silent forwarding to an external address. Every email Rahul receives from now on also goes to the attacker. Even after you kick them out, if you miss this rule, they keep reading his email.

File downloads SharePoint, 3 files, 25 MB. Whatever those files contained, the attacker has them now.

OAuth app consent this is the sneaky one. The attacker added an OAuth application to the account. OAuth tokens survive password resets. So if you reset Rahul's password and don't specifically check and revoke OAuth app permissions, the attacker still has access. I've seen this catch incident responders off guard more than once.

--------------------------------------------------------------------------------------------------------------

Why this is harder to catch than malware

This attack maps to MITRE ATT&CK T1078 Valid Accounts. No payload. No exploit. No EDR alert. Everything the attacker did was technically legitimate from the system's perspective because they were operating inside a real, authenticated session.

Your SIEM has no way to distinguish "Rahul downloaded files" from "attacker using Rahul's session downloaded files" without behavioral context. That's why the baseline matters. That's why timeline reconstruction matters.

The attacker didn't break in. They logged in.

--------------------------------------------------------------------------------------------------------------

What I would have faced if I delayed this by even few minutes

The inbox forwarding rule was already running. Every email coming into that account was silently copying to an attacker controlled address. If Rahul was CC'd on anything sensitive in the next few hours be it project files, client data, internal announcements, it was ufff gone.

The OAuth app meant the attacker had a backdoor that survives a password reset. You could kick them out, reset everything, and they'd be back in quietly the next day through the app they already authorized.

And the internal email account thing is what actually scares me most. An email from rahul[.]sharma@company[.]com(Notice how I defang it) to another internal employee doesn't trigger the same suspicion as an external phishing email. Attacker could have used that account to phish colleagues, get someone else to click something, and then you have a second compromised account from a trusted internal sender.

That's how these escalate from one account to a full lateral compromise.

--------------------------------------------------------------------------------------------------------------

What I did to contain it(Response Actions Stuff)

Disabled the account immediately. Forced password reset. Killed all active sessions. Re-enrolled MFA fresh on a verified device.

Then the cleanup: removed the forwarding rule, revoked the OAuth app, reviewed 7 days of sent email history to check if the account had already been used to send anything malicious, forced sign-out across all tenants.

Called the customer, as mentioned earlier, walked them through what happened.

--------------------------------------------------------------------------------------------------------------

I'll add the KQL queries for pulling Azure AD sign in anomalies and inbox rule creation events if enough people want it, just say so in the comments and I'll do a follow-up.

--------------------------------------------------------------------------------------------------------------

Upvote and save this if you found it useful. Share it with someone prepping for SOC interviews, this is the kind of thinking that actually gets you hired.

Also, let me know what else do you want me to break down? Drop it in the comments.

Wanted to drop this here because I've seen a lot of posts asking how to investigate alerts that look normal/benign so let me share a real case from a few days back at my work.

Warning: long post. Lots of detail. I think it'll change how you look at identity alerts. But worth it if you're learning security work.

--------------------------------------------------------------------------------------------------------------

Few days back, after lunch, I get an alert. Azure AD, suspicious login. I almost scrolled past it.

No malware. No exploit. Just a login that succeeded.

Alert/Detection Raw Data (Changed from actual data, for obvious privacy reasons):

Timestamp: 2026-06-19 02:11:07
User: rahul.sharma@company.com
Result: SUCCESS
Source IP: 185.234.72.91
Location: Romania
Device: Windows 10 (Unknown)
Application: Exchange Online
MFA: Passed

Now on the surface, nothing here screams incident/malicious. It's a successful login. MFA passed. System says everything's fine.

But something felt wrong(can say it gut feeling after dealing with 100s of detections), so I kept going.

--------------------------------------------------------------------------------------------------------------

First thing I always do: baseline the user

Before I call anything suspicious, I pull 30 days of login history for that account. Takes 2 minutes, saves you from false positives and helps you build a real case if it is malicious.

This user, Rahul, in this case, always logged in from Bangalore. MacBook. Corporate VPN. 9 AM to 7 PM window. Every single day for 30 days.

Current login: Romania. Unknown Windows machine. 2 AM. No VPN.

Zero overlap. Not a single normal parameter matched.

That's when I stopped treating it as suspicious and started treating it as a compromise.

--------------------------------------------------------------------------------------------------------------

Then I reconstructed the full timeline

This is the part most people skip and it's the most important thing you can do. Pull SIEM + M365 logs together and build out exactly what happened, minute by minute.

This is what I found(actual logs don't look like this, below is a simplified version):

02:09:11 → Failed login
02:09:40 → Failed login  
02:10:02 → Failed login
02:11:07 → SUCCESS

02:12:30 → Accessed Exchange mailbox
02:14:10 → Created inbox rule: forward all emails to external address
02:18:54 → Logged into SharePoint
02:22:11 → Downloaded 3 files (~25 MB)
02:25:40 → Second login, same IP
02:30:02 → OAuth app consent granted

Three failures then a clean success. And then 18 minutes of very specific, deliberate actions.

Real users don't behave like this. Real users open their email, check something, close it. They don't create forwarding rules and download files at 2 in the morning within 10 minutes of logging in.

This is what attackers look like when they get in. They already know what they want and they move fast.

--------------------------------------------------------------------------------------------------------------

The MFA thing and this is what most people don't understand

MFA passed. I called the user. He said he had no idea what I was talking about, didn't approve any prompt, was asleep.

So how does MFA pass without the user?

There are two ways this happens and both are common enough that you'll see them if you work in MDR/SOC long enough.

AiTM phishing: the attacker sets up a reverse proxy site that looks exactly like the real login page. User gets a phishing link, goes to the fake page, enters their credentials. The proxy forwards everything to Microsoft in real time. Microsoft sends MFA to the user's phone. User approves it thinking it's normal. But the attacker's proxy captures the authenticated session token before the user gets redirected to the real dashboard. Now the attacker has a valid, MFA authenticated session token. They don't need the password anymore.

Token replay: attacker already had a session token from an older compromise or cookie theft. Token wasn't expired yet. No new MFA challenge triggered at all.

Either way, this is the thing to understand. MFA protects your password. It does not protect your session. Once an attacker has a valid session token, MFA has already done its job from the system's perspective. You're logged in.

--------------------------------------------------------------------------------------------------------------

The IP Part, hardly takes 10 sec, but tells you a lot

"185[.]234[.]xx[.]xx"(pro tip: always defang the IP/URL) ran it through a couple of threat intel sources. Hosted on a cloud provider, not a residential ISP. Flagged as suspicious across multiple feeds.

Normal users don't log in from hosting providers at 2 AM. That's either a VPS someone rented or a compromised server being used as a jump point.

--------------------------------------------------------------------------------------------------------------

Post-login activity is what actually confirmed the compromise

The login itself is suspicious. What happened after is what closes the case.

Inbox forwarding rule attacker set up silent forwarding to an external address. Every email Rahul receives from now on also goes to the attacker. Even after you kick them out, if you miss this rule, they keep reading his email.

File downloads SharePoint, 3 files, 25 MB. Whatever those files contained, the attacker has them now.

OAuth app consent this is the sneaky one. The attacker added an OAuth application to the account. OAuth tokens survive password resets. So if you reset Rahul's password and don't specifically check and revoke OAuth app permissions, the attacker still has access. I've seen this catch incident responders off guard more than once.

--------------------------------------------------------------------------------------------------------------

Why this is harder to catch than malware

This attack maps to MITRE ATT&CK T1078 Valid Accounts. No payload. No exploit. No EDR alert. Everything the attacker did was technically legitimate from the system's perspective because they were operating inside a real, authenticated session.

Your SIEM has no way to distinguish "Rahul downloaded files" from "attacker using Rahul's session downloaded files" without behavioral context. That's why the baseline matters. That's why timeline reconstruction matters.

The attacker didn't break in. They logged in.

--------------------------------------------------------------------------------------------------------------

What I would have faced if I delayed this by even few minutes

The inbox forwarding rule was already running. Every email coming into that account was silently copying to an attacker controlled address. If Rahul was CC'd on anything sensitive in the next few hours be it project files, client data, internal announcements, it was ufff gone.

The OAuth app meant the attacker had a backdoor that survives a password reset. You could kick them out, reset everything, and they'd be back in quietly the next day through the app they already authorized.

And the internal email account thing is what actually scares me most. An email from rahul[.]sharma@company[.]com(Notice how I defang it) to another internal employee doesn't trigger the same suspicion as an external phishing email. Attacker could have used that account to phish colleagues, get someone else to click something, and then you have a second compromised account from a trusted internal sender.

That's how these escalate from one account to a full lateral compromise.

--------------------------------------------------------------------------------------------------------------

What I did to contain it(Response Actions Stuff)

Disabled the account immediately. Forced password reset. Killed all active sessions. Re-enrolled MFA fresh on a verified device.

Then the cleanup: removed the forwarding rule, revoked the OAuth app, reviewed 7 days of sent email history to check if the account had already been used to send anything malicious, forced sign-out across all tenants.

Called the customer, as mentioned earlier, walked them through what happened.

--------------------------------------------------------------------------------------------------------------

I'll add the KQL queries for pulling Azure AD sign in anomalies and inbox rule creation events if enough people want it, just say so in the comments and I'll do a follow-up.

--------------------------------------------------------------------------------------------------------------

Upvote and save this if you found it useful. Share it with someone prepping for SOC interviews, this is the kind of thinking that actually gets you hired.

Also, let me know what else do you want me to break down? Drop it in the comments.

Wanted to drop this here because I've seen a lot of posts asking how to investigate alerts that look normal/benign so let me share a real case from a few days back at my work.

Warning: long post. Lots of detail. I think it'll change how you look at identity alerts. But worth it if you're learning security work.

--------------------------------------------------------------------------------------------------------------

Few days back, after lunch, I get an alert. Azure AD, suspicious login. I almost scrolled past it.

No malware. No exploit. Just a login that succeeded.

Alert/Detection Raw Data (Changed from actual data, for obvious privacy reasons):

Timestamp: 2026-06-19 02:11:07
User: rahul.sharma@company.com
Result: SUCCESS
Source IP: 185.234.72.91
Location: Romania
Device: Windows 10 (Unknown)
Application: Exchange Online
MFA: Passed

Now on the surface, nothing here screams incident/malicious. It's a successful login. MFA passed. System says everything's fine.

But something felt wrong(can say it gut feeling after dealing with 100s of detections), so I kept going.

--------------------------------------------------------------------------------------------------------------

First thing I always do: baseline the user

Before I call anything suspicious, I pull 30 days of login history for that account. Takes 2 minutes, saves you from false positives and helps you build a real case if it is malicious.

This user, Rahul, in this case, always logged in from Bangalore. MacBook. Corporate VPN. 9 AM to 7 PM window. Every single day for 30 days.

Current login: Romania. Unknown Windows machine. 2 AM. No VPN.

Zero overlap. Not a single normal parameter matched.

That's when I stopped treating it as suspicious and started treating it as a compromise.

--------------------------------------------------------------------------------------------------------------

Then I reconstructed the full timeline

This is the part most people skip and it's the most important thing you can do. Pull SIEM + M365 logs together and build out exactly what happened, minute by minute.

This is what I found(actual logs don't look like this, below is a simplified version):

02:09:11 → Failed login
02:09:40 → Failed login  
02:10:02 → Failed login
02:11:07 → SUCCESS

02:12:30 → Accessed Exchange mailbox
02:14:10 → Created inbox rule: forward all emails to external address
02:18:54 → Logged into SharePoint
02:22:11 → Downloaded 3 files (~25 MB)
02:25:40 → Second login, same IP
02:30:02 → OAuth app consent granted

Three failures then a clean success. And then 18 minutes of very specific, deliberate actions.

Real users don't behave like this. Real users open their email, check something, close it. They don't create forwarding rules and download files at 2 in the morning within 10 minutes of logging in.

This is what attackers look like when they get in. They already know what they want and they move fast.

--------------------------------------------------------------------------------------------------------------

The MFA thing and this is what most people don't understand

MFA passed. I called the user. He said he had no idea what I was talking about, didn't approve any prompt, was asleep.

So how does MFA pass without the user?

There are two ways this happens and both are common enough that you'll see them if you work in MDR/SOC long enough.

AiTM phishing: the attacker sets up a reverse proxy site that looks exactly like the real login page. User gets a phishing link, goes to the fake page, enters their credentials. The proxy forwards everything to Microsoft in real time. Microsoft sends MFA to the user's phone. User approves it thinking it's normal. But the attacker's proxy captures the authenticated session token before the user gets redirected to the real dashboard. Now the attacker has a valid, MFA authenticated session token. They don't need the password anymore.

Token replay: attacker already had a session token from an older compromise or cookie theft. Token wasn't expired yet. No new MFA challenge triggered at all.

Either way, this is the thing to understand. MFA protects your password. It does not protect your session. Once an attacker has a valid session token, MFA has already done its job from the system's perspective. You're logged in.

--------------------------------------------------------------------------------------------------------------

The IP Part, hardly takes 10 sec, but tells you a lot

"185[.]234[.]xx[.]xx"(pro tip: always defang the IP/URL) ran it through a couple of threat intel sources. Hosted on a cloud provider, not a residential ISP. Flagged as suspicious across multiple feeds.

Normal users don't log in from hosting providers at 2 AM. That's either a VPS someone rented or a compromised server being used as a jump point.

--------------------------------------------------------------------------------------------------------------

Post-login activity is what actually confirmed the compromise

The login itself is suspicious. What happened after is what closes the case.

Inbox forwarding rule attacker set up silent forwarding to an external address. Every email Rahul receives from now on also goes to the attacker. Even after you kick them out, if you miss this rule, they keep reading his email.

File downloads SharePoint, 3 files, 25 MB. Whatever those files contained, the attacker has them now.

OAuth app consent this is the sneaky one. The attacker added an OAuth application to the account. OAuth tokens survive password resets. So if you reset Rahul's password and don't specifically check and revoke OAuth app permissions, the attacker still has access. I've seen this catch incident responders off guard more than once.

--------------------------------------------------------------------------------------------------------------

Why this is harder to catch than malware

This attack maps to MITRE ATT&CK T1078 Valid Accounts. No payload. No exploit. No EDR alert. Everything the attacker did was technically legitimate from the system's perspective because they were operating inside a real, authenticated session.

Your SIEM has no way to distinguish "Rahul downloaded files" from "attacker using Rahul's session downloaded files" without behavioral context. That's why the baseline matters. That's why timeline reconstruction matters.

The attacker didn't break in. They logged in.

--------------------------------------------------------------------------------------------------------------

What I would have faced if I delayed this by even few minutes

The inbox forwarding rule was already running. Every email coming into that account was silently copying to an attacker controlled address. If Rahul was CC'd on anything sensitive in the next few hours be it project files, client data, internal announcements, it was ufff gone.

The OAuth app meant the attacker had a backdoor that survives a password reset. You could kick them out, reset everything, and they'd be back in quietly the next day through the app they already authorized.

And the internal email account thing is what actually scares me most. An email from rahul[.]sharma@company[.]com(Notice how I defang it) to another internal employee doesn't trigger the same suspicion as an external phishing email. Attacker could have used that account to phish colleagues, get someone else to click something, and then you have a second compromised account from a trusted internal sender.

That's how these escalate from one account to a full lateral compromise.

--------------------------------------------------------------------------------------------------------------

What I did to contain it(Response Actions Stuff)

Disabled the account immediately. Forced password reset. Killed all active sessions. Re-enrolled MFA fresh on a verified device.

Then the cleanup: removed the forwarding rule, revoked the OAuth app, reviewed 7 days of sent email history to check if the account had already been used to send anything malicious, forced sign-out across all tenants.

Called the customer, as mentioned earlier, walked them through what happened.

--------------------------------------------------------------------------------------------------------------

I'll add the KQL queries for pulling Azure AD sign in anomalies and inbox rule creation events if enough people want it, just say so in the comments and I'll do a follow-up.

--------------------------------------------------------------------------------------------------------------

If you're trying to build this kind of investigative thinking, the kind where you're not just reading alerts but actually reconstructing what happened, that's exactly what I'm working on with my webinar series.

Thank you for everyone who joined the First Part (Phishing) of My Webinar Series and making it houseful.

The second one is on 4th July: Live Malware Triage: Real SOC Investigation. Same format as the first one, no slides, no theory, just a live screen share, a real alert, and my full thought process on screen. The first part was well received, this one goes deeper.

The recording won't be available for free this time. Seats are limited.

Register Link in bio if you're interested.

--------------------------------------------------------------------------------------------------------------

Upvote and save this if you found it useful. Share it with someone prepping for SOC interviews, this is the kind of thinking that actually gets you hired.

Also, let me know what else do you want me to break down? Drop it in the comments.

Wanted to drop this here because I've seen a lot of posts asking how to investigate alerts that look normal/benign so let me share a real case from a few days back at my work.

Warning: long post. Lots of detail. I think it'll change how you look at identity alerts. But worth it if you're learning security work.

--------------------------------------------------------------------------------------------------------------

Few days back, after lunch, I get an alert. Azure AD, suspicious login. I almost scrolled past it.

No malware. No exploit. Just a login that succeeded.

Alert/Detection Raw Data (Changed from actual data, for obvious privacy reasons):

Timestamp: 2026-06-19 02:11:07
User: rahul.sharma@company.com
Result: SUCCESS
Source IP: 185.234.72.91
Location: Romania
Device: Windows 10 (Unknown)
Application: Exchange Online
MFA: Passed

Now on the surface, nothing here screams incident/malicious. It's a successful login. MFA passed. System says everything's fine.

But something felt wrong(can say it gut feeling after dealing with 100s of detections), so I kept going.

--------------------------------------------------------------------------------------------------------------

First thing I always do: baseline the user

Before I call anything suspicious, I pull 30 days of login history for that account. Takes 2 minutes, saves you from false positives and helps you build a real case if it is malicious.

This user, Rahul, in this case, always logged in from Bangalore. MacBook. Corporate VPN. 9 AM to 7 PM window. Every single day for 30 days.

Current login: Romania. Unknown Windows machine. 2 AM. No VPN.

Zero overlap. Not a single normal parameter matched.

That's when I stopped treating it as suspicious and started treating it as a compromise.

--------------------------------------------------------------------------------------------------------------

Then I reconstructed the full timeline

This is the part most people skip and it's the most important thing you can do. Pull SIEM + M365 logs together and build out exactly what happened, minute by minute.

This is what I found(actual logs don't look like this, below is a simplified version):

02:09:11 → Failed login
02:09:40 → Failed login  
02:10:02 → Failed login
02:11:07 → SUCCESS

02:12:30 → Accessed Exchange mailbox
02:14:10 → Created inbox rule: forward all emails to external address
02:18:54 → Logged into SharePoint
02:22:11 → Downloaded 3 files (~25 MB)
02:25:40 → Second login, same IP
02:30:02 → OAuth app consent granted

Three failures then a clean success. And then 18 minutes of very specific, deliberate actions.

Real users don't behave like this. Real users open their email, check something, close it. They don't create forwarding rules and download files at 2 in the morning within 10 minutes of logging in.

This is what attackers look like when they get in. They already know what they want and they move fast.

--------------------------------------------------------------------------------------------------------------

The MFA thing and this is what most people don't understand

MFA passed. I called the user. He said he had no idea what I was talking about, didn't approve any prompt, was asleep.

So how does MFA pass without the user?

There are two ways this happens and both are common enough that you'll see them if you work in MDR/SOC long enough.

AiTM phishing: the attacker sets up a reverse proxy site that looks exactly like the real login page. User gets a phishing link, goes to the fake page, enters their credentials. The proxy forwards everything to Microsoft in real time. Microsoft sends MFA to the user's phone. User approves it thinking it's normal. But the attacker's proxy captures the authenticated session token before the user gets redirected to the real dashboard. Now the attacker has a valid, MFA authenticated session token. They don't need the password anymore.

Token replay: attacker already had a session token from an older compromise or cookie theft. Token wasn't expired yet. No new MFA challenge triggered at all.

Either way, this is the thing to understand. MFA protects your password. It does not protect your session. Once an attacker has a valid session token, MFA has already done its job from the system's perspective. You're logged in.

--------------------------------------------------------------------------------------------------------------

The IP Part, hardly takes 10 sec, but tells you a lot

"185[.]234[.]xx[.]xx"(pro tip: always defang the IP/URL) ran it through a couple of threat intel sources. Hosted on a cloud provider, not a residential ISP. Flagged as suspicious across multiple feeds.

Normal users don't log in from hosting providers at 2 AM. That's either a VPS someone rented or a compromised server being used as a jump point.

--------------------------------------------------------------------------------------------------------------

Post-login activity is what actually confirmed the compromise

The login itself is suspicious. What happened after is what closes the case.

Inbox forwarding rule attacker set up silent forwarding to an external address. Every email Rahul receives from now on also goes to the attacker. Even after you kick them out, if you miss this rule, they keep reading his email.

File downloads SharePoint, 3 files, 25 MB. Whatever those files contained, the attacker has them now.

OAuth app consent this is the sneaky one. The attacker added an OAuth application to the account. OAuth tokens survive password resets. So if you reset Rahul's password and don't specifically check and revoke OAuth app permissions, the attacker still has access. I've seen this catch incident responders off guard more than once.

--------------------------------------------------------------------------------------------------------------

Why this is harder to catch than malware

This attack maps to MITRE ATT&CK T1078 Valid Accounts. No payload. No exploit. No EDR alert. Everything the attacker did was technically legitimate from the system's perspective because they were operating inside a real, authenticated session.

Your SIEM has no way to distinguish "Rahul downloaded files" from "attacker using Rahul's session downloaded files" without behavioral context. That's why the baseline matters. That's why timeline reconstruction matters.

The attacker didn't break in. They logged in.

--------------------------------------------------------------------------------------------------------------

What I would have faced if I delayed this by even few minutes

The inbox forwarding rule was already running. Every email coming into that account was silently copying to an attacker controlled address. If Rahul was CC'd on anything sensitive in the next few hours be it project files, client data, internal announcements, it was ufff gone.

The OAuth app meant the attacker had a backdoor that survives a password reset. You could kick them out, reset everything, and they'd be back in quietly the next day through the app they already authorized.

And the internal email account thing is what actually scares me most. An email from rahul[.]sharma@company[.]com(Notice how I defang it) to another internal employee doesn't trigger the same suspicion as an external phishing email. Attacker could have used that account to phish colleagues, get someone else to click something, and then you have a second compromised account from a trusted internal sender.

That's how these escalate from one account to a full lateral compromise.

--------------------------------------------------------------------------------------------------------------

What I did to contain it(Response Actions Stuff)

Disabled the account immediately. Forced password reset. Killed all active sessions. Re-enrolled MFA fresh on a verified device.

Then the cleanup: removed the forwarding rule, revoked the OAuth app, reviewed 7 days of sent email history to check if the account had already been used to send anything malicious, forced sign-out across all tenants.

Called the customer, as mentioned earlier, walked them through what happened.

--------------------------------------------------------------------------------------------------------------

I'll add the KQL queries for pulling Azure AD sign in anomalies and inbox rule creation events if enough people want it, just say so in the comments and I'll do a follow-up.

--------------------------------------------------------------------------------------------------------------

If you're trying to build this kind of investigative thinking, the kind where you're not just reading alerts but actually reconstructing what happened, that's exactly what I'm working on with my webinar series.

Thank you for everyone who joined the First Part (Phishing) of My Webinar Series and making it houseful.

The second one is on 4th July: Live Malware Triage: Real SOC Investigation. Same format as the first one, no slides, no theory, just a live screen share, a real alert, and my full thought process on screen. The first part was well received, this one goes deeper.

The recording won't be available for free this time. Seats are limited.

Register Link in bio if you're interested.

--------------------------------------------------------------------------------------------------------------

Upvote and save this if you found it useful. Share it with someone prepping for SOC interviews, this is the kind of thinking that actually gets you hired.

Also, let me know what else do you want me to break down? Drop it in the comments.

Thank you for showing so much support on Part 1, which ended with the C2 beacon. The implant was calling home every five minutes.

But what happens if the machine reboots? What if the user restarts their laptop? Does the attacker lose access?

No. And that's the dark part.

This is persistence. And it's where attackers make their biggest mistakes.

After the malware landed on Karan's machine, the attacker did two things to make sure they'd stay inside even if the machine powered down.

First: they added a registry run key. Specifically, they wrote svchost32.exe to HKLM\Software\Microsoft\Windows\CurrentVersion\Run. Auto-start. Every login. The file path? C:\Users\karan.verma\AppData\Roaming\svchost32.exe the exact payload that came through the macro.

Why name it svchost32.exe?
Because the real Windows service is svchost.exe. One extra character. Just like the phishing domain. Lookalike naming. It blends in if someone's looking at running processes casually. But it doesn't blend in if you're actually investigating.

Second they created two scheduled tasks. Both designed to restart the C2 beacon if it dies. One runs every 15 minutes. One every hour. If the implant gets killed, these tasks bring it back.

This is the difference between an attacker who got in and an attacker who intends to stay.

When I ran the registry queries in front of you guys and pulled the scheduled tasks from the endpoint, the timeline became clear:

• 06:44: Phishing email delivered
• 06:50: Macro executed, payload downloaded
• 06:55: C2 beacon established (five-minute intervals start)
• 07:12: Persistence mechanisms written to registry
• 07:15: Scheduled tasks created

The attacker was in and securing their foothold within 31 minutes.

The irony was that they made it easier to catch them. The registry keys. The scheduled tasks. The deliberate naming. All of it left traces. All of it told the story.

Most students focus on detecting the initial compromise, catching the macro, seeing the PowerShell command, finding the C2. That's Part 1.

But Part 2 is where you find out the attacker's been planning to stay. And that changes your containment strategy entirely.

You're not just killing a process. You're removing registry keys. You're deleting scheduled tasks. You're rebuilding trust in the machine. You're asking what else did they touch? What did they exfil? How long were they actually inside?

The full investigation timeline, the queries, how to spot the AppData folders that scream "not legitimate Windows," and what the containment call actually looks like, that's all in the video.

For those grinding toward your first SOC role this is the stuff that separates analysts who understand incident response from analysts who understand alerts. Persistence is where you prove you actually know what you're doing.

The attacker thought they were safe. They weren't.

Thank you for showing so much support on Part 1, which ended with the C2 beacon. The implant was calling home every five minutes.

But what happens if the machine reboots? What if the user restarts their laptop? Does the attacker lose access?

No. And that's the dark part.

This is persistence. And it's where attackers make their biggest mistakes.

After the malware landed on Karan's machine, the attacker did two things to make sure they'd stay inside even if the machine powered down.

First: they added a registry run key. Specifically, they wrote svchost32.exe to HKLM\Software\Microsoft\Windows\CurrentVersion\Run. Auto-start. Every login. The file path? C:\Users\karan.verma\AppData\Roaming\svchost32.exe the exact payload that came through the macro.

Why name it svchost32.exe?
Because the real Windows service is svchost.exe. One extra character. Just like the phishing domain. Lookalike naming. It blends in if someone's looking at running processes casually. But it doesn't blend in if you're actually investigating.

Second they created two scheduled tasks. Both designed to restart the C2 beacon if it dies. One runs every 15 minutes. One every hour. If the implant gets killed, these tasks bring it back.

This is the difference between an attacker who got in and an attacker who intends to stay.

When I ran the registry queries in front of you guys and pulled the scheduled tasks from the endpoint, the timeline became clear:

• 06:44: Phishing email delivered
• 06:50: Macro executed, payload downloaded
• 06:55: C2 beacon established (five-minute intervals start)
• 07:12: Persistence mechanisms written to registry
• 07:15: Scheduled tasks created

The attacker was in and securing their foothold within 31 minutes.

The irony was that they made it easier to catch them. The registry keys. The scheduled tasks. The deliberate naming. All of it left traces. All of it told the story.

Most students focus on detecting the initial compromise, catching the macro, seeing the PowerShell command, finding the C2. That's Part 1.

But Part 2 is where you find out the attacker's been planning to stay. And that changes your containment strategy entirely.

You're not just killing a process. You're removing registry keys. You're deleting scheduled tasks. You're rebuilding trust in the machine. You're asking what else did they touch? What did they exfil? How long were they actually inside?

The full investigation timeline, the queries, how to spot the AppData folders that scream "not legitimate Windows," and what the containment call actually looks like, that's all in the video.

For those grinding toward your first SOC role this is the stuff that separates analysts who understand incident response from analysts who understand alerts. Persistence is where you prove you actually know what you're doing.

The attacker thought they were safe. They weren't.

Thank you for showing so much support on Part 1, which ended with the C2 beacon. The implant was calling home every five minutes.

But what happens if the machine reboots? What if the user restarts their laptop? Does the attacker lose access?

No. And that's the dark part.

This is persistence. And it's where attackers make their biggest mistakes.

After the malware landed on Karan's machine, the attacker did two things to make sure they'd stay inside even if the machine powered down.

First: they added a registry run key. Specifically, they wrote svchost32.exe to HKLM\Software\Microsoft\Windows\CurrentVersion\Run. Auto-start. Every login. The file path? C:\Users\karan.verma\AppData\Roaming\svchost32.exe the exact payload that came through the macro.

Why name it svchost32.exe?
Because the real Windows service is svchost.exe. One extra character. Just like the phishing domain. Lookalike naming. It blends in if someone's looking at running processes casually. But it doesn't blend in if you're actually investigating.

Second they created two scheduled tasks. Both designed to restart the C2 beacon if it dies. One runs every 15 minutes. One every hour. If the implant gets killed, these tasks bring it back.

This is the difference between an attacker who got in and an attacker who intends to stay.

When I ran the registry queries in front of you guys and pulled the scheduled tasks from the endpoint, the timeline became clear:

• 06:44: Phishing email delivered
• 06:50: Macro executed, payload downloaded
• 06:55: C2 beacon established (five-minute intervals start)
• 07:12: Persistence mechanisms written to registry
• 07:15: Scheduled tasks created

The attacker was in and securing their foothold within 31 minutes.

The irony was that they made it easier to catch them. The registry keys. The scheduled tasks. The deliberate naming. All of it left traces. All of it told the story.

Most students focus on detecting the initial compromise, catching the macro, seeing the PowerShell command, finding the C2. That's Part 1.

But Part 2 is where you find out the attacker's been planning to stay. And that changes your containment strategy entirely.

You're not just killing a process. You're removing registry keys. You're deleting scheduled tasks. You're rebuilding trust in the machine. You're asking what else did they touch? What did they exfil? How long were they actually inside?

The full investigation timeline, the queries, how to spot the AppData folders that scream "not legitimate Windows," and what the containment call actually looks like, that's all in the video.

For those grinding toward your first SOC role this is the stuff that separates analysts who understand incident response from analysts who understand alerts. Persistence is where you prove you actually know what you're doing.

The attacker thought they were safe. They weren't.

Thank you for showing so much support on Part 1, which ended with the C2 beacon. The implant was calling home every five minutes.

But what happens if the machine reboots? What if the user restarts their laptop? Does the attacker lose access?

No. And that's the dark part.

This is persistence. And it's where attackers make their biggest mistakes.

After the malware landed on Karan's machine, the attacker did two things to make sure they'd stay inside even if the machine powered down.

First: they added a registry run key. Specifically, they wrote svchost32.exe to HKLM\Software\Microsoft\Windows\CurrentVersion\Run. Auto-start. Every login. The file path? C:\Users\karan.verma\AppData\Roaming\svchost32.exe the exact payload that came through the macro.

Why name it svchost32.exe?
Because the real Windows service is svchost.exe. One extra character. Just like the phishing domain. Lookalike naming. It blends in if someone's looking at running processes casually. But it doesn't blend in if you're actually investigating.

Second they created two scheduled tasks. Both designed to restart the C2 beacon if it dies. One runs every 15 minutes. One every hour. If the implant gets killed, these tasks bring it back.

This is the difference between an attacker who got in and an attacker who intends to stay.

When I ran the registry queries in front of you guys and pulled the scheduled tasks from the endpoint, the timeline became clear:

• 06:44: Phishing email delivered
• 06:50: Macro executed, payload downloaded
• 06:55: C2 beacon established (five-minute intervals start)
• 07:12: Persistence mechanisms written to registry
• 07:15: Scheduled tasks created

The attacker was in and securing their foothold within 31 minutes.

The irony was that they made it easier to catch them. The registry keys. The scheduled tasks. The deliberate naming. All of it left traces. All of it told the story.

Most students focus on detecting the initial compromise, catching the macro, seeing the PowerShell command, finding the C2. That's Part 1.

But Part 2 is where you find out the attacker's been planning to stay. And that changes your containment strategy entirely.

You're not just killing a process. You're removing registry keys. You're deleting scheduled tasks. You're rebuilding trust in the machine. You're asking what else did they touch? What did they exfil? How long were they actually inside?

The full investigation timeline, the queries, how to spot the AppData folders that scream "not legitimate Windows," and what the containment call actually looks like, that's all in the video.

For those grinding toward your first SOC role this is the stuff that separates analysts who understand incident response from analysts who understand alerts. Persistence is where you prove you actually know what you're doing.

The attacker thought they were safe. They weren't.

So on 16 May 2026 (Saturday) I ran a live session for students who wanted to see what actual threat analysis looks like. Not the sanitized course version. The real thing, sitting in front of an alert, zero context, figuring out what the hell happened in real time.

Thank you to everyone who attended the webinar.

158 people registered. Over 50 stuck through the whole thing. A lot of them had never seen this part of the job before.

The setup was simple: phishing email lands in the SOC queue. Subject line says "Your wallet has been Blocked." Legitimate looking. Urgent. Classic social engineering. But here's what actually went down when I investigated it.

The email came from info@metamaask[.]io note the extra 'A'. One character lookalike domain. It bypassed email filters on 6 mailboxes. 2 got caught. 4 didn't.

From there it gets worse. The attachment is an Excel file with macros. User opens it. Macro executes. Spawns PowerShell with an encoded command. Downloads a second-stage payload. Implant ends up running on the host.

Then we tracked the C2 beaconing in network logs. Seven connections to the attacker's server, exactly five minutes apart. Every. Single. Time. That precision isn't a human, it's the malware checking in on a timer. Port 443, disguised as normal HTTPS traffic.

That's the full chain. Email to implant running in minutes.

I walked through all of this using actual queries, real endpoint telemetry, and network logs. The way it actually works at my Job. No slides. No theory. Just the investigation.

For those targeting your first SOC role this is what the job actually looks like. Not the tool walkthroughs. Not the labs. This. Sitting with incomplete data, using your tools to build the picture, making calls fast and accurate.

If you want specific guidance on breaking into SOC or want me to review where you're stuck, drop a comment or DM me.

So on 16 May 2026 (Saturday) I ran a live session for students who wanted to see what actual threat analysis looks like. Not the sanitized course version. The real thing, sitting in front of an alert, zero context, figuring out what the hell happened in real time.

Thank you to everyone who attended the webinar.

158 people registered. Over 50 stuck through the whole thing. A lot of them had never seen this part of the job before.

The setup was simple: phishing email lands in the SOC queue. Subject line says "Your wallet has been Blocked." Legitimate looking. Urgent. Classic social engineering. But here's what actually went down when I investigated it.

The email came from info@metamaask[.]io note the extra 'A'. One character lookalike domain. It bypassed email filters on 6 mailboxes. 2 got caught. 4 didn't.

From there it gets worse. The attachment is an Excel file with macros. User opens it. Macro executes. Spawns PowerShell with an encoded command. Downloads a second-stage payload. Implant ends up running on the host.

Then we tracked the C2 beaconing in network logs. Seven connections to the attacker's server, exactly five minutes apart. Every. Single. Time. That precision isn't a human, it's the malware checking in on a timer. Port 443, disguised as normal HTTPS traffic.

That's the full chain. Email to implant running in minutes.

I walked through all of this using actual queries, real endpoint telemetry, and network logs. The way it actually works at my Job. No slides. No theory. Just the investigation.

For those targeting your first SOC role this is what the job actually looks like. Not the tool walkthroughs. Not the labs. This. Sitting with incomplete data, using your tools to build the picture, making calls fast and accurate.

If you want specific guidance on breaking into SOC or want me to review where you're stuck, drop a comment or DM me.

So on 16 May 2026 (Saturday) I ran a live session for students who wanted to see what actual threat analysis looks like. Not the sanitized course version. The real thing, sitting in front of an alert, zero context, figuring out what the hell happened in real time.

Thank you to everyone who attended the webinar.

158 people registered. Over 50 stuck through the whole thing. A lot of them had never seen this part of the job before.

The setup was simple: phishing email lands in the SOC queue. Subject line says "Your wallet has been Blocked." Legitimate looking. Urgent. Classic social engineering. But here's what actually went down when I investigated it.

The email came from info@metamaask[.]io note the extra 'A'. One character lookalike domain. It bypassed email filters on 6 mailboxes. 2 got caught. 4 didn't.

From there it gets worse. The attachment is an Excel file with macros. User opens it. Macro executes. Spawns PowerShell with an encoded command. Downloads a second-stage payload. Implant ends up running on the host.

Then we tracked the C2 beaconing in network logs. Seven connections to the attacker's server, exactly five minutes apart. Every. Single. Time. That precision isn't a human, it's the malware checking in on a timer. Port 443, disguised as normal HTTPS traffic.

That's the full chain. Email to implant running in minutes.

I walked through all of this using actual queries, real endpoint telemetry, and network logs. The way it actually works at my Job. No slides. No theory. Just the investigation.

For those targeting your first SOC role this is what the job actually looks like. Not the tool walkthroughs. Not the labs. This. Sitting with incomplete data, using your tools to build the picture, making calls fast and accurate.

If you want specific guidance on breaking into SOC or want me to review where you're stuck, drop a comment or DM me.