Threat hunting — hypothesis, ATT&CK আর log-এ খোঁজা

১ · অ্যালার্ম আর তল্লাশি — alerting বনাম hunting

একটি পোশাক কারখানার গুদাম ভাবুন। দরজায় অ্যালার্ম আছে। তালা ভাঙলে ঘণ্টা বাজবে। কিন্তু কেউ যদি নকল পরিচয়পত্র নিয়ে স্বাভাবিকভাবে ঢোকে, ঘণ্টা বাজবে না। তাই মাসে একবার হিসাবরক্ষক রেজিস্টার খাতা, গেটের স্লিপ আর গুদামের মাল মিলিয়ে দেখেন। কোনো ঘণ্টা বাজেনি, তবুও তিনি খোঁজেন। কারণ তাঁর প্রশ্ন আলাদা: “ঘণ্টা বাজেনি বলে কি সব ঠিক আছে?”

Detection rule হলো ওই ঘণ্টা। আর threat hunting হলো হিসাব মেলানোর কাজ। TaHiTI নথির সংজ্ঞায় hunting হলো IT পরিকাঠামোতে, বর্তমান ও অতীত দুই সময়েই, এমন ক্ষতিকর কাজের চিহ্ন সক্রিয়ভাবে খোঁজা, যা চালু প্রতিরক্ষাকে এড়িয়ে গেছে। মূল কথাটি হলো মানুষ প্রশ্ন তোলেন, আর tool সেই প্রশ্নের উত্তর খুঁজতে সাহায্য করে।

Hunting কেন দরকার? কারণ আক্রমণকারী যত কম শব্দ করে, dwell time তত বাড়ে। অর্থাৎ ঢোকা আর ধরা পড়ার মাঝের সময় লম্বা হয়। অনেক কাজ বৈধ account আর সাধারণ admin tool দিয়েই হয়, যাকে living off the land বলে। সেসব কাজে rule বসালে false positive-এর বন্যা নামে। পর্ব ০৫-এ এজন্যই বলা হয়েছিল, কিছু আচরণ alert নয়, hunting-এর জন্য রাখুন। David Bianco-র Pyramid of Pain অনুযায়ী TTP বদলানো আক্রমণকারীর জন্য সবচেয়ে কঠিন। Hunting মূলত সেই স্তরেই কাজ করে।

২ · শুরুর আগে — log, baseline, মানুষ আর maturity

খাতা না থাকলে হিসাব মেলানো যায় না। Hunting-এর আগে তিনটি জিনিস লাগে:

David Bianco-র তৈরি Hunting Maturity Model (HMM) প্রতিষ্ঠানের সক্ষমতা মাপে। Sqrrl-এর ২০১৫ সালের লেখায় এর বিবরণ আছে। এতে পাঁচটি স্তর আছে। স্তর ঠিক হয় ডেটার পরিমাণ ও মান, tool আর analyst-এর দক্ষতা দেখে।

HM0 আর HM4 দুই জায়গাতেই automation আছে, কিন্তু অর্থ আলাদা। HM0-তে দল alert-এর জন্য বসে থাকে। HM4-এ দল নিজের আবিষ্কারকে automation-এ পরিণত করে এগিয়ে যায়। মূল লেখার ভাষায়, hunting মেশিনের সাহায্য নিতে পারে, কিন্তু তা analyst-চালিত, পুরোপুরি automate করা যায় না।

৩ · Hunting loop — একটি hunt-এর পুরো পথ

একবার খুঁজলেই নেটওয়ার্ক চিরকালের জন্য নিরাপদ হয়ে যায় না। তাই Sqrrl দল ২০১৫ সালে hunting-কে একটি চক্র হিসেবে আঁকে। একে hunting loop বলে। এর চারটি ধাপ:

এবার একটি কাল্পনিক অনলাইন বাজারের পুরো hunt দেখুন। সংখ্যাগুলো toy, কিন্তু ধাপগুলো বাস্তব। “পরে” চাপুন।

Hypothesis : গত ৩০ দিনে কোনো document app
             PowerShell চালিয়েছে
ATT&CK     : T1566.001 > T1204.002 > T1059.001
Data       : process creation log, ৪০টি PC
Time-box   : ৮ ঘণ্টা

PC reporting   : 40 / 40
Time range     : 30 days
Parent field   : present
Events (toy)   : 1,024

count  hosts  pair
    1      1  winword.exe > powershell.exe
    3      2  excel.exe > splwow64.exe
    4      1  excel.exe > powershell.exe
   30      1  backup-agent.exe > cmd.exe
... আরও ৫টি সাধারণ জোড়া

10:41  outlook.exe > winword.exe  (mail attachment)
10:41  winword.exe > powershell.exe
10:42  proxy: pc-17 > 203.0.113.50
10:47  proxy: pc-17 > 203.0.113.50
10:52  proxy: pc-17 > 203.0.113.50

Verdict   : confirmed, open incident
Handed to : incident response team
Kept      : queries, timeline, evidence list
Do not    : log off, wipe, or alert the user yet

First draft : 14 hits, 1 true   precision 7.1%
Finance job : 12 hits, reviewed, narrow filter
After filter:  2 hits, 1 true   precision 50.0%

৪ · ভালো hypothesis কীভাবে বানাবেন

Hunting hypothesis হলো এমন একটি অনুমান, যা log দেখে সত্য বা মিথ্যা বলা যায়। “হ্যাকার থাকতে পারে” কোনো hypothesis নয়, কারণ এটি কখনো ভুল প্রমাণ করা যায় না। TaHiTI-ও সতর্ক করে যে দুর্বল hypothesis ফলহীন বা ভুল সিদ্ধান্তে নিয়ে যেতে পারে।

Hypothesis সাধারণত তিন জায়গা থেকে আসে:

একটি hypothesis বাছাইয়ের সময় তিনটি প্রশ্ন করুন: ঘটলে ক্ষতি কত, আমাদের log-এ দেখা যাবে কি, আর এখনকার rule এটি ধরে কি না? Sqrrl-এর লেখাও বলে, আগে দেখুন কোনটি alert-এ ইতিমধ্যে ধরা পড়ে, তারপর বাকিটা খুঁজুন।

৫ · Stacking আর long tail — বিরল জিনিস গুনে বের করা

বাজারের হিসাব ভাবুন। হাজারটি বিক্রি রশিদের মধ্যে বেশিরভাগ চাল, ডাল, তেল। কিন্তু একটি রশিদে লেখা “১টি অচেনা জিনিস, নগদে, রাত ১১টায়।” সব রশিদ পড়তে হবে না। শুধু জিনিস ধরে গুনে নিচের দিকের সারি দেখলেই হয়।

একেই বলে stacking বা stack counting: একটি বৈশিষ্ট্য ধরে ঘটনা গোনা। গুনে সাজালে সাধারণত অল্প কিছু সারিতে বেশিরভাগ ঘটনা থাকে। বাকি অনেক সারিতে থাকে সামান্য কিছু। এই সরু লেজটিকে long tail বলে, আর সেখানে নজর দেওয়াই long-tail analysis. এর পেছনের ধারণা least frequency of occurrence (LFO): আক্রমণকারীর কাজ সাধারণত অল্প জায়গায়, অল্পবার ঘটে, তাই নিচের সারিতে ভেসে ওঠে।

নিচের toy উদাহরণে parent-child process জোড়া stack করা হয়েছে। মানে কোন program কোন program-কে চালিয়েছে। Run চাপুন।

// toy: কাল্পনিক ৩০ দিনের process log, real নয়
const seed = [ // parent, child, ঘটনা, কয়টি PC-তে
  ['explorer.exe', 'chrome.exe', 412, 38],
  ['services.exe', 'svchost.exe', 240, 40],
  ['explorer.exe', 'outlook.exe', 180, 38],
  ['svchost.exe', 'updater.exe', 96, 40],
  ['explorer.exe', 'excel.exe', 58, 21],
  ['backup-agent.exe', 'cmd.exe', 30, 1],
  ['excel.exe', 'powershell.exe', 4, 1],
  ['excel.exe', 'splwow64.exe', 3, 2],
  ['winword.exe', 'powershell.exe', 1, 1],
];
const events = [];
for (const [p, c, n, h] of seed)
  for (let i = 0; i < n; i++)
    events.push({ host: 'pc-' + (i % h + 1), pair: p + ' > ' + c });

const stack = new Map();
for (const e of events) {
  const row = stack.get(e.pair) || { count: 0, hosts: new Set() };
  row.count++;
  row.hosts.add(e.host);
  stack.set(e.pair, row);
}
const rows = [...stack].sort((a, b) => a[1].count - b[1].count);
console.log('total events:', events.length, ' distinct pairs:', rows.length);
console.log('count    pct  hosts  pair');
for (const [pair, r] of rows) {
  const pct = (100 * r.count / events.length).toFixed(2);
  const mark = r.hosts.size <= 2 ? '  <- review' : '';
  console.log(String(r.count).padStart(5), pct.padStart(6),
    String(r.hosts.size).padStart(6), ' ' + pair + mark);
}

ফল পাওয়াই শেষ নয়, পড়তে জানতে হয়। “বিরল” মানেই “খারাপ” নয়। নিচে একই ফল সারি ধরে পড়া হলো।

1   1   1  winword.exe > powershell.exe2   3   2  excel.exe > splwow64.exe3   4   1  excel.exe > powershell.exe4  30   1  backup-agent.exe > cmd.exe5  58  21  explorer.exe > excel.exe6  96  40  svchost.exe > updater.exe7 180  38  explorer.exe > outlook.exe8 240  40  services.exe > svchost.exe9 412  38  explorer.exe > chrome.exe

একই কৌশল সাধারণ Unix tool দিয়েও হয়। নিচের Bash block একটি ছোট নমুনা proxy log নিজেই বানায়, তারপর user-agent ধরে stack করে। ব্যবস্থাটি আপনার নিজের অনুমোদিত log-এ একইভাবে কাজ করবে।

# toy proxy log: সময়, PC, user-agent (block নিজেই ফাইলটি বানায়)
cat > proxy.log <<'EOF'
09:01 pc-01 Chrome/130
09:02 pc-02 Chrome/130
09:03 pc-03 Edge/130
09:05 pc-04 Chrome/130
09:07 pc-01 Updater/3.1
09:07 pc-02 Updater/3.1
09:07 pc-03 Updater/3.1
09:07 pc-04 Updater/3.1
09:11 pc-02 Chrome/130
09:14 pc-03 Edge/130
09:20 pc-05 Chrome/130
09:21 pc-05 Updater/3.1
09:26 pc-06 Edge/130
09:31 pc-02 curl/8.5
09:33 pc-02 curl/8.5
09:34 pc-02 curl/8.5
09:38 pc-01 Chrome/130
09:40 pc-04 Edge/130
09:42 pc-06 PyClient/2.0
09:47 pc-05 Chrome/130
EOF
export LC_ALL=C
echo "== events per user-agent =="
cut -d' ' -f3 proxy.log | sort | uniq -c | sort -n
echo "== distinct PCs per user-agent =="
cut -d' ' -f2,3 proxy.log | sort -u | cut -d' ' -f2 | sort | uniq -c | sort -n
echo "== full lines of the rarest =="
grep 'PyClient' proxy.log

৬ · আরও কৌশল — baseline, clustering আর time series

মিলিয়ে ব্যবহার করুন। একটি কৌশল একটি সূত্র দেয়, প্রমাণ দেয় না। সূত্র মিললে আস্থা বাড়ে। Stacking-এ বিরল জোড়া, তার ওপর time series-এ নিয়মিত যোগাযোগ, দুটো একসঙ্গে অনেক শক্তিশালী ইঙ্গিত।

৭ · নিজের log-এ পাঁচটি hunt

নিচের প্রতিটি hunt আপনার নিজের প্রতিষ্ঠানের log-এ, অনুমোদন নিয়ে করার জন্য। এখানে শুধু কী দেখবেন, সেটি বলা হয়েছে।

Hunt ১: বিরল parent-child process জোড়া

ATT&CK: T1059. Log: process creation (Windows Event 4688, Sysmon Event 1 বা EDR). Document app, web server বা database process থেকে shell চলা অস্বাভাবিক। উপরের stacking এই hunt-এরই উদাহরণ। ব্যাখ্যা ভালো করে দেয় process tree.

Hunt ২: Beaconing

ATT&CK: T1071. Log: proxy, DNS, flow record. মানুষ অনিয়মিতভাবে browse করেন। স্বয়ংক্রিয় program প্রায় সমান বিরতিতে যোগাযোগ করে। এই নিয়মিততা মাপা যায় coefficient of variation (CV) দিয়ে:

CV শূন্যের কাছে মানে খুব নিয়মিত। তবে software update, antivirus, health check আর NTP-ও নিয়মিত যোগাযোগ করে। আবার সব ক্ষতিকর যোগাযোগ নিখুঁত ছন্দে চলে না। তাই CV-র সঙ্গে destination-এর বয়স, কতগুলো PC সেখানে যায়, আর কে সেখানে যায়, এসবও দেখতে হয়।

Hunt ৩: নতুন admin account

ATT&CK: T1098, T1136. Log: Windows Event 4728, 4732, identity provider-এর audit log. এখানে কৌশলটি first-seen analysis: আগে কখনো না দেখা জিনিস প্রথমবার দেখলেই নজর দেওয়া। সঙ্গে change ticket মিলিয়ে দেখলে সুযোগ আরও কমে।

// toy: admin group-এ সদস্য যোগের কাল্পনিক ঘটনা
const known = new Set(['it-lead', 'root-it']); // ৯০ দিনের baseline
const tickets = new Set(['CHG-1042']);        // অনুমোদিত change
const events = [
  { day: 4, actor: 'it-lead', member: 'helpdesk-2', ticket: 'CHG-1042' },
  { day: 9, actor: 'it-lead', member: 'it-lead', ticket: null },
  { day: 12, actor: 'helpdesk-2', member: 'svc-report', ticket: null },
  { day: 13, actor: 'root-it', member: 'db-admin-1', ticket: 'CHG-9999' },
  { day: 15, actor: 'helpdesk-2', member: 'svc-report', ticket: null },
];
let leads = 0;
for (const e of events) {
  let verdict;
  if (known.has(e.member)) {
    verdict = 'seen before, skip';
  } else if (e.ticket && tickets.has(e.ticket)) {
    verdict = 'FIRST SEEN, ticket ok, add to baseline';
    known.add(e.member); // শুধু অনুমোদিত হলেই baseline-এ
  } else {
    const why = e.ticket ? 'ticket not found' : 'no ticket';
    verdict = 'FIRST SEEN, ' + why + ' -> LEAD';
    leads++;
  }
  console.log(`day ${String(e.day).padStart(2)}  ${e.actor} added ` +
    `${e.member}: ${verdict}`);
}
console.log('leads for a human:', leads, ' of', events.length, 'events');
console.log('baseline now:', [...known].sort().join(', '));

Hunt ৪: অস্বাভাবিক logon সময়

ATT&CK: T1078 Valid Accounts. Log: logon log, IdP sign-in log. সবার জন্য একই “অফিস সময়” ধরলে রাতের দল বারবার ধরা পড়ে। প্রতি user-এর নিজের baseline ধরা ভালো। ঘড়ি গোল, এটিও মনে রাখতে হয়।

// toy: প্রতি user-এর গত ৩০ দিনের logon ঘণ্টা (০–২৩)
const baseline = {
  'user-a': [9, 9, 10, 9, 10, 9, 11, 9, 10, 9, 18],
  'noc-1': [22, 23, 23, 0, 0, 1, 22, 23, 0, 1, 2],
  'user-b': [10, 11, 10, 19, 20, 19, 10, 11, 20, 19, 10],
};
// ঘড়ি গোল: 23 আর 0-র দূরত্ব 1, 23 নয়
const gap = (a, b) => { const d = Math.abs(a - b); return Math.min(d, 24 - d); };
const support = (hours, h) => hours.filter((x) => gap(x, h) <= 1).length;
const mean = (a) => a.reduce((s, x) => s + x, 0) / a.length;

const MIN_SUPPORT = 2; // কাছাকাছি সময়ে অন্তত ২ বার আগে দেখা চাই
const logons = [['user-a', 9], ['user-a', 3], ['noc-1', 1],
                ['user-b', 20], ['user-c', 10]];
console.log('naive mean hour of noc-1:', mean(baseline['noc-1']).toFixed(1));
console.log('user    hour  global-rule  per-user');
for (const [u, h] of logons) {
  const office = h >= 8 && h <= 19 ? 'ok' : 'FLAG';
  let mine;
  if (!baseline[u]) mine = 'no baseline, cannot judge';
  else {
    const s = support(baseline[u], h);
    mine = (s >= MIN_SUPPORT ? 'ok' : 'LEAD') + ' (support ' + s + ')';
  }
  console.log(u.padEnd(7), String(h).padStart(4), office.padStart(12), ' ' + mine);
}

Hunt ৫: Data transfer spike

ATT&CK: T1041, T1567. Log: firewall, proxy, cloud storage. Exfiltration ধরতে প্রতি host থেকে বাইরে যাওয়া byte মাপুন। ধরুন আগের ১০ দিনের upload (MB): 120, 135, 110, 150, 125, 140, 130, 115, 145, 130. Mean ১৩০ MB, SD প্রায় ১২.২ MB. আজ 2,400 MB, অর্থাৎ ২,৪০০ ÷ ১৩০ ≈ ১৮.৫ গুণ। এটি স্পষ্ট spike, কিন্তু backup, ভিডিও সম্পাদনা বা নতুন cloud sync-ও হতে পারে। Upload-এর ডেটায় প্রায়ই অল্প কয়েকটি মান অনেক বড় হয় (skewed), তাই বাস্তবে mean-এর সঙ্গে median-ও দেখুন। এরপর প্রশ্ন: কোথায় গেল, কে পাঠাল, আগে কখনো সেখানে গিয়েছে কি না?

৮ · নথি, কিছু না পাওয়া আর hunt থেকে নতুন rule

লেখা না থাকলে hunt হারিয়ে যায়। একটি hunt report ছোট হতে পারে, কিন্তু এতে থাকা চাই: hypothesis, ATT&CK ID, data ও সময়সীমা, query, ফল, যা দেখা যায়নি, আর পরের কাজ। মূল প্রশ্ন হলো, ছয় মাস পরে অন্য কেউ কি hunt-টি আবার চালাতে পারবেন?

ক্ষতিকর কিছু না পাওয়া ব্যর্থতা নয়। TaHiTI ফলকে proven, disproven আর inconclusive এই তিন ভাগে রাখে। এমনকি প্রয়োজনীয় data না থাকলে hunt ব্যর্থ ধরা হলেও তা থেকে শেখা যায়। নিচের কাল্পনিক hunt-টি দেখুন।

Hunt থেকে স্বয়ংক্রিয় detection

একই hunt বারবার হাতে করা সময়ের অপচয়। সফল query-কে detection rule বানালে মানুষ পরের প্রশ্নে যেতে পারেন। এই কাজের নাম detection engineering. Sigma নিয়ে বিস্তারিত পর্ব ৫৬-এ। নিচের উদাহরণটি আগের hunt থেকে বানানো একটি নমুনা rule, শুধু পড়ার জন্য। Filter সরু: একটি নির্দিষ্ট PC আর একটি নির্দিষ্ট ফাইল।

title: Document App Starts PowerShell
id: 5b7e2c1a-3f4d-4e8a-9c21-7d6f0a1b2c3d
status: experimental
description: A document app started PowerShell. Found by a hunt; review each hit.
author: Example SOC
date: 2026-10-31
tags:
  - attack.execution
  - attack.t1059.001
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    ParentImage|endswith:
      - '\winword.exe'
      - '\excel.exe'
    Image|endswith: '\powershell.exe'
  filter_finance_report:
    Computer: 'pc-03'
    ParentCommandLine|contains: 'month-end-report.xlsm'
  condition: selection and not filter_finance_report
falsepositives:
  - Approved reporting macros, each with an owner and an expiry date
level: medium

Rule চালুর আগে চারটি কাজ করুন। এক, পুরোনো log-এ replay করে hit গুনুন। দুই, precision হিসাব করুন: ১/১৪ ≈ ৭.১%, filter-এর পরে ১/২ = ৫০%. তিন, প্রত্যাশিত চাপ দেখুন: ৯০ দিনে ২টি hit মানে মাসে প্রায় ০.৬৭টি alert, যা সামলানো যায়। চার, purple team বা একটি নিরীহ পরীক্ষা দিয়ে দেখুন, rule সত্যিই alert দেয় কি না। প্রতিটি rule exclusion-এর মালিক আর মেয়াদ থাকা চাই। সব hunt rule হয় না। যা খুব শব্দবহুল, সেটি নিয়মিত report বা পরের hunt-এর জন্য থাকুক।

৯ · Cloud-এ hunting, privacy-র সীমা আর time-box

Cloud-এ hunting

Cloud-এ process-এর চেয়ে identity আর API call বেশি গুরুত্বপূর্ণ। মূল উৎস cloud audit log, যেমন AWS CloudTrail, Azure Activity Log বা Google Cloud Audit Logs, আর IdP-র sign-in log. একই কৌশল এখানেও চলে: কোন identity কোন API কতবার ডেকেছে, সেটি stack করুন। প্রথমবার দেখা region, নতুন access key, হঠাৎ public হওয়া storage বা নতুন role grant, এসব ভালো সূত্র। সতর্কতা হলো, অনেক provider-এ data-স্তরের log আলাদা করে চালু করতে হয়, আর container খুব অল্প সময় বাঁচে। তাই log কেন্দ্রীয়ভাবে রাখুন (Centralized logging, Cloud security posture). পর্ব ৭২-এ cloud নিরাপত্তা বিস্তারে আসবে।

কর্মীর ডেটা আর privacy

Log-এর বড় অংশ মানুষের কাজের রেকর্ড। Hunt যেন নজরদারিতে না গড়ায়, সেজন্য কয়েকটি সীমা দরকার:

• উদ্দেশ্যে বাঁধা: Hunt হবে নিরাপত্তার প্রশ্নে। কারও কাজের গতি মাপা বা ব্যক্তিগত ব্রাউজিং দেখা নয়।
• Data minimization: Metadata দিয়ে কাজ চললে email বা chat-এর লেখা খোলা যাবে না। সম্ভব হলে নামের বদলে pseudonymization, অর্থাৎ ছদ্ম ID ব্যবহার করুন।
• আগে থেকে নীতি: কর্মীদের জানানো, লিখিত নীতি আর আইনি পরামর্শ। Monitoring-এর সীমা প্রতিষ্ঠানের নীতিতে থাকা চাই।
• রক্ষককেও পাহারা: Hunting tool-এর ব্যবহার নিজেও log হবে। কে কী খুঁজেছে, তা audit করা যাবে।
• ব্যক্তিকে নিশানা নয়: কোনো কর্মীর ওপর সন্দেহ হলে hunter নিজে অনুসরণ করবেন না। বিষয়টি HR, আইন বিভাগ আর ঊর্ধ্বতনের অনুমোদিত প্রক্রিয়ায় যাবে (insider threat-এর ক্ষেত্রেও)।

GDPR-এর data minimization নীতি আর বাংলাদেশের ব্যক্তিগত উপাত্ত সুরক্ষা আইন, ২০২৬ (৬৩ নং) এখানে প্রাসঙ্গিক হতে পারে। আইনের কিছু ধারা পরে gazette-এর মাধ্যমে কার্যকর হবে। এই পর্ব আইনি পরামর্শ নয়। বিস্তারিত পর্ব ০৬ আর পর্ব ৭০-এ।

Time-box

Time-boxing মানে শুরুতেই সময় বেঁধে দেওয়া। ধরুন ৮ ঘণ্টা। সময় শেষে তিনটি পথ: ফল লিখে শেষ, স্পষ্ট কারণে সময় বাড়ানো, অথবা নতুন hunt হিসেবে backlog-এ রাখা। সন্দেহের কিছু পেলে time-box থামে না, ঘটনা incident response-এ যায়। সীমা না থাকলে hunt অনন্ত খননে পরিণত হয়, আর দল alert সামলানোর সময় হারায়।

১০ · AI-এর যুগে threat hunting

AI hypothesis-এর খসড়া, query অনুবাদ আর রিপোর্টের সারাংশে দ্রুত সাহায্য করতে পারে। কিন্তু সে আপনার পরিবেশ চেনে না, আর ভুল উত্তরও আত্মবিশ্বাস নিয়ে দেয়। সিদ্ধান্ত থাকবে মানুষের হাতে।

AI ব্যবহারের চেকলিস্ট

• Prompt-এ আসল log, secret, ব্যক্তিগত ডেটা দিইনি
• প্রতিটি ATT&CK ID আর standard প্রাথমিক উৎসে মিলিয়েছি
• Query একটি জানা নমুনায় চালিয়ে দেখেছি যে সেটি ধরতে পারে
• AI-এর রায়কে সূত্র ধরেছি, প্রমাণ নয়
• মানুষকে প্রভাবিত করে এমন সিদ্ধান্ত মানুষই নিয়েছেন