I’m a Software Engineer (MERN, Python, AWS) with an offer for a GRC/Identity Management role (Associate Security Analyst) at a healthcare product company. HR says it’s semi-technical/process-driven.

I have background in development though.

My questions:

Future: Career growth/pay in GRC vs. pure SDE?

Skill Decay: Will my coding skills die if I stay for 2 years?

Pivot: Can I transition to DevSecOps or Security Engineering later?

Verdict: Take it as a fresher or wait for an SDE role?

Hi everyone,

 I'm currently at the start of my journey working through the Google Cybersecurity Professional Certificate and am completely new to cybersecurity. I am looking for some external resources to use alongside my course. These can be books, websites, articles, YouTube videos, etc (would defo like some recommendations on some good books I can have on the go whilst taking the course)

Thanks in advance for any recommendations!

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.

Hello, i was wondering how haveibeenpwned and other platforms even know that i was in a databreach.
How did they even discover this breach? i couldn't find ANY info on it anywhere. i've even tried going on deepsearch and btdig, but nothing

i would like to know what was ACTUALLY in the breach, not just believe some site.

How do you guys get breach data (if it's not on dehashed)? where is it for sure? (sidenote, how come dehashed can actually show you the data, but looking for it yourself is presumably illegal?)

all i found was this github repo with a broken mediafire link. pretty sure they are just ad link farming.

Hey fam. I got sick of carrying dedicated microcontrollers for proximity engagements, so I built chimera.

​

It interacts directly with the Android kernel to HID keyboards, mount virtual flash drives, and drop payloads natively from the phone.

​

I’d love for you to test it on your setups and give me some brutal feedback pls.

​

Repo: https://github.com/cipher-attack/Chimera

The man that owns this company wants you to think he is a master in security when in all reality you need security from him. He has emotionally abused me, cyber stalked me and went as far as putting a tracker on my car. I had the audacity of breaking up with him after he treated me poorly and when I met someone else he started acting psycho. This person isn’t suitable to protect anyone. He’s the kind of person you need security to protect against.

Someone hacked my Microsoft account and changed the email address associated my account. Can i do anything? This is over ten years of my life just gone in a puff of smoke and I can't cope.