Concepts: Phishing, MITM, Online Banking Security

How Phishing Works — Dissecting a Real Attack

Phishing is not as simple as “a fake email.” Modern phishing is carefully engineered to exploit how humans think and behave. Let us dissect a real example.

Here is an email that has circulated widely in India:

From: support@sbi-netbanking.in Subject: Urgent: Your SBI Net Banking Access Has Been Suspended

Dear Customer, Your SBI Net Banking account has been locked due to multiple failed login attempts. To unlock immediately, click the link below and verify your details within 24 hours or your account will be permanently disabled. [Verify Now] → sbi-netbanking-unlock.com

Let us go through it element by element:

support@sbi-netbanking.in — The sender address looks official but is not. SBI’s real domain is sbi.co.in. Anyone can register sbi-netbanking.in for a few hundred rupees.

“Dear Customer” — No personalisation. Your bank knows your name and would use it.

“locked due to multiple failed login attempts” — This creates alarm. Your instinct is to fix it immediately.

“within 24 hours” — Urgency removes your thinking time. Attackers rely on this.

sbi-netbanking-unlock.com — Not onlinesbi.sbi. Not sbi.co.in. A domain registered by the attacker. If you check WHOIS, it was registered days ago.

“permanently disabled” — A threat. Designed to prevent you from stopping to think.

Deepa Asks

“If it’s so obvious when you analyse it, why do so many people fall for it?”

Because in real life, you do not sit down and analyse your SMS messages. You are at work. You are worried. You just made three online purchases and maybe one of them did trigger a security alert. You are on mobile, so the URL is abbreviated in your SMS app. You tap without thinking. Attackers have studied human psychology for years. The message is designed for the moment of least resistance.

The Anatomy of a Phishing Site

Once you click the link, the phishing site is waiting:

  • It looks exactly like SBI’s real site — the attacker used a web scraper to copy the HTML, CSS, and images
  • The URL in the address bar reads sbi-yono-unlock.com — but on mobile, only the first part is visible
  • It has an HTTPS padlock — the attacker got a free certificate from Let’s Encrypt in five minutes
  • It asks for your account number, password, and OTP
  • When you submit, your credentials go to the attacker’s server
  • The site shows a “Thank you, your account is now unlocked” message
  • You think the problem is solved. Your account has just been emptied.

How to Spot Phishing

Red FlagWhat to Check
Urgency or threatsReal banks do not threaten you via SMS
Unusual domainCheck the full URL — does it end in sbi.co.in?
Asks for OTPYour bank will never ask for your OTP
Poor grammarNot definitive, but suspicious
No personalisation“Dear Customer” instead of your name
Recently registered domainCheck WHOIS — age matters

The Golden Rule

No legitimate bank, government office, or payment system will ever ask for your OTP, PIN, or full card number via SMS, phone call, or a link you clicked. OTPs are one-time verification — they exist precisely so that only you can use them, in the moment, for the specific transaction you initiated. If someone else asks for it, they are stealing it.

Man-in-the-Middle (MITM) Attacks

Rohan is at the airport. He sees a Wi-Fi network called “Free_Airport_WiFi”. He connects. What he does not know is that a person sitting nearby set up that hotspot using their phone. Every packet Rohan sends goes through the attacker’s device first.

For HTTP sites, the attacker can read everything. For HTTPS sites, the story is more complicated.

Does HTTPS protect against MITM?

Yes — with a caveat. If you are connected to a legitimate HTTPS site and an attacker intercepts your traffic, they see only encrypted data. They cannot read it. They cannot modify it without breaking the certificate verification.

But — and this is the caveat — if the attacker can also get your device to trust a certificate they control (for example, by tricking you into installing a rogue Certificate Authority), they can decrypt and re-encrypt your traffic in real time. This is why:

  • You should never install custom certificates unless you know exactly what you are doing
  • Corporate devices often have corporate CAs installed for IT monitoring — your employer can technically see your HTTPS traffic on a work device

SSL Strip

An older but important attack: when you type sbi.co.in without https://, your browser first connects via HTTP and then gets redirected to HTTPS. An attacker on your network can intercept that first HTTP connection and serve you a fake HTTP page, stripping the HTTPS before it starts. The protection against this is HSTS — if you have visited a site before with HSTS, your browser remembers to always use HTTPS and never makes that initial HTTP request.

DNS Spoofing

In Session 1, you learned that DNS converts domain names to IP addresses. What if an attacker could give you a false answer?

DNS spoofing (also called DNS cache poisoning) is when an attacker inserts a false DNS record so that your device looks up sbi.co.in and gets the IP address of the attacker’s server instead of SBI’s real server.

On a controlled network (like a compromised home router or a malicious public Wi-Fi), this is achievable. HTTPS and certificate verification are your protection: even if DNS sends you to the wrong IP, the server at that IP cannot present a valid certificate for sbi.co.in (because only SBI’s server has the corresponding private key). Your browser would show a certificate error.

This is another reason why certificate verification matters so much: it is the last line of defence when DNS cannot be trusted.

How Online Banking Login Works — and Why It Is Well Designed

Every day, millions of people log into their bank accounts online in India. Very few experience fraud through the banking system itself — because banks have layered security into every step of the login and transfer process.

Here is the full flow of an online banking login and transfer:

You
    ↓ Enter username + password on the bank's HTTPS site
Bank's Web Server
    ↓ Verifies credentials against its database (password is hashed, never stored in plaintext)
    ↓ Generates a one-time OTP and sends it to your registered mobile number
You
    ↓ Enter the OTP within its validity window (usually 3–5 minutes)
Bank's Server
    ↓ Verifies OTP, creates an encrypted session token for your browser
    ↓ Logs the login: your IP address, device fingerprint, timestamp
You (now logged in)
    ↓ Initiate a transfer — bank may ask for OTP again for high-value transactions
Bank's Server
    ↓ Processes transfer, sends SMS confirmation to your registered number
    ↓ Session expires after inactivity (typically 5–10 minutes)

Where security is applied:

  • Your password is never stored in plaintext. The bank stores only a secure hash. Even bank employees cannot see your password.
  • All communication uses TLS encryption with certificate verification — your browser verified the bank’s certificate before you typed a single character.
  • The OTP is tied to your registered SIM. Even if an attacker knows your password, they cannot log in without your phone.
  • Session tokens expire. Even if someone steals your session cookie, it becomes useless after you log out or after inactivity.
  • Login attempts from new devices or unusual locations trigger additional verification.

Rohan Goes Deeper

The OTP step is called 2FA (Two-Factor Authentication) — it requires something you know (password) and something you have (your phone). Banks use TOTP (Time-based One-Time Password) standards — the OTP is mathematically derived from the current time and a shared secret, so it expires automatically. Even if someone intercepts an OTP over the network, it is useless 60 seconds later.

Why most online banking fraud is social engineering, not system hacking:

Attackers do not break bank encryption or crack passwords. Instead, they:

  • Send phishing emails that redirect to fake login pages to harvest credentials
  • Call victims posing as bank support and talk them into sharing their OTP
  • Use screen-sharing apps to watch victims type their credentials and OTP in real time

The common thread: the attacker needs the victim to take an action. The bank’s systems are sound. Human behaviour is the attack surface.

Network Troubleshooting — Thinking in Layers

When something is not working on a network, Sunita didi has a mental script she runs through on support calls. It mirrors the internet’s layered architecture:

  1. Is the device connected? Can you ping an IP address? → If yes, the physical/network layer works
  2. Is DNS working? Can you resolve domain names? → If ping-by-name fails but ping-by-IP works, it is a DNS problem
  3. Is the server reachable? Can you reach the server’s port? → If DNS works but the page does not load, it is an application or firewall issue
  4. Is the application working? Does the right content load? → If the server responds but the page looks wrong, it is an application issue

Thinking in layers prevents you from jumping to conclusions. “The internet is broken” is almost never true. Something specific at a specific layer is broken.

Key Takeaway

Attackers target the weakest link — and the weakest link is almost always human behaviour, not cryptographic algorithms. HTTPS, certificates, and online banking’s layered security are technically sound. The gap is between knowing you should check the sender’s email address and the URL, and actually doing it in a moment of panic or haste. Awareness is the defence.