AI agent ছয় ঘণ্টায় হাজারো credential তুলেছে—response window এখন কত ছোট
Google Threat Intelligence Group (GTIG) ৮ সেপ্টেম্বর প্রকাশিত threat tracker-এ জানায়, ২০২৬ সালের দ্বিতীয় প্রান্তিকে সন্দেহভাজন আর্থিকভাবে অনুপ্রাণিত এক হামলাকারী একটি প্রতিষ্ঠানের cloud infrastructure দখল করে সেখানে autonomous multi-agent framework বসিয়েছিল। একটি AI coding chatbot, prompt ও agent instruction কাজে লাগিয়ে frameworkটি ছয় ঘণ্টার কম সময়ে mass credential-harvesting campaign পরিকল্পনা, তৈরি ও চালায়; GTIG-এর প্রাথমিক প্রতিবেদনে হাজারো third-party credential compromise হওয়ার কথা রয়েছে।
৮ সেপ্টেম্বর প্রকাশিত এই তথ্যের তাৎপর্য হলো, ছয় ঘণ্টা initial compromise ঘটার সময় নয়—cloud foothold পাওয়ার পর campaign তৈরি ও চালানোর সময়। ফলে title-এর “response window” কোনো আনুষ্ঠানিক ছয় ঘণ্টার deadline নয়; attacker-এর গতি দেখে প্রতিরক্ষার জরুরি সিদ্ধান্তগুলো মিনিট ও ঘণ্টাভিত্তিক করার বাস্তব প্রয়োজন।
ছয় ঘণ্টার মধ্যে frameworkটি যা করেছে
এটি নিয়ন্ত্রিত পরীক্ষা বা প্রকাশ্য benchmark ছিল না। Mandiant-এর incident-response পর্যবেক্ষণে attacker নাম প্রকাশ না করা প্রতিষ্ঠানের cloud infrastructure ব্যবহার করেছে। Preconfigured Markdown instruction set operational playbook হিসেবে scanning ও credential harvesting পরিচালনা করেছে; ব্যর্থতা দেখা দিলে frameworkটি real-time troubleshooting এবং মানুষের হাতে প্রতিটি ধাপ ছাড়াই IP rotation করতে পেরেছে।
The Hacker News-এর ঘটনাবিবরণে financially motivated actor, AI coding chatbot, automated scanning, troubleshooting এবং IP rotation-এর একই তথ্য পাওয়া যায়। তবে প্রকাশিত বর্ণনায় initial access কীভাবে হয়েছিল, কোন দুর্বলতা কাজে লেগেছিল কিংবা ঠিক কোন cloud provider আক্রান্ত হয়েছিল—তা বলা হয়নি।
Credential theft নতুন কৌশল নয়; বদলটি এসেছে orchestration ও গতিতে। Scanner আটকে গেলে framework troubleshooting করতে, pipeline সচল রাখতে এবং egress address বদলাতে পেরেছে। আক্রান্ত প্রতিষ্ঠানের cloud থেকে traffic যাওয়ায় destination-এর কাছে সেটি বৈধ cloud IP-originated request বলে মনে হওয়ার সম্ভাবনাও তৈরি হয়েছে।
‘Autonomous’ শব্দটির সীমা কোথায়
ঘটনাটিকে সম্পূর্ণ মানুষহীন cyberattack বলা ঠিক হবে না। মানুষ প্রথমে cloud infrastructure compromise করেছে এবং chatbot, prompt, instruction ও playbook দিয়ে framework প্রস্তুত করেছে। Autonomy দেখা গেছে পরের operational loop-এ—scanning pipeline পরিচালনা, error সামলানো, credential harvesting এবং IP rotation-এ manual handholding কমেছে।
GTIG একই threat tracker-এ স্পষ্ট করেছে, বাস্তব target-এর বিরুদ্ধে threat actor পরিচালিত সম্পূর্ণ autonomous exploitation pipeline তারা এখনো পর্যবেক্ষণ করেনি। অর্থাৎ কোনো AI নিজে target বেছে নিয়ে শূন্য থেকে intrusion শুরু করেছে—এমন প্রমাণ এই ঘটনায় নেই।
IT Pro-এর ৯ সেপ্টেম্বরের বিশ্লেষণ victim cloud-এর legitimate IP দিয়ে traffic চালানো এবং কম human intervention-এ workflow সচল রাখার বিষয়টি পুনরায় তুলে ধরেছে। দুটি সংবাদ প্রতিবেদনই GTIG-এর গবেষণার ওপর নির্ভরশীল; এগুলো আলাদা incident investigation নয়।
কোন signal একসঙ্গে দেখলে campaignটি ধরা সহজ
Agentic activity শনাক্ত করতে কোনো “AI” label খোঁজা যথেষ্ট নয়। বেশি কার্যকর সংকেত হলো একই workload বা identity ঘিরে cloud control-plane change, secret access এবং outbound network activity-এর ধারাবাহিকতা। প্রতিটি alert আলাদাভাবে low severity ধরে রাখলে পুরো operation-এর গতি চোখ এড়িয়ে যেতে পারে।
- Cloud control plane: অচেনা principal-এর token creation, service-account impersonation, নতুন role binding, compute বা container deployment এবং firewall বা route পরিবর্তন মিলিয়ে দেখুন।
- Developer ও CI/CD: runner, build job বা artifact process কোন repository token, environment secret, deploy key কিংবা package-registry credential পড়েছে, তার timeline তৈরি করুন।
- Agent configuration: coding-assistant workspace, instruction file, Markdown playbook ও hidden project directory-তে অপ্রত্যাশিত file creation বা পরিবর্তন খুঁজুন।
- Network ও identity: একটি workload থেকে বহু host বা port-এ connection, অস্বাভাবিক authentication burst, দ্রুত বদলানো egress এবং সফল login-এর পর API enumeration একই timeline-এ আনুন।
Cloud audit, identity-provider, secret manager, CI/CD, repository, DNS, proxy ও flow log-এর timestamp একটি অভিন্ন UTC timeline-এ রাখা এখানে গুরুত্বপূর্ণ। শুধু endpoint alert দেখলে cloud API-তে ব্যবহৃত key বাদ যেতে পারে; শুধু identity log দেখলে attacker-controlled workload-এর scanning আচরণ অনুপস্থিত থাকবে।
প্রথম ছয় ঘণ্টার containment order
নিচের সময়বিন্যাস GTIG প্রকাশিত কোনো runbook নয়। এটি campaignটির ছয় ঘণ্টার কম সময়সীমা ধরে ছোট cloud ও DevOps দলের জন্য ঝুঁকিভিত্তিক সম্পাদকীয় অগ্রাধিকার। উদ্দেশ্য হলো পূর্ণ forensic certainty-এর অপেক্ষায় attacker-এর access সচল না রাখা, আবার containment করতে গিয়ে প্রয়োজনীয় evidence নষ্ট না করা।
- প্রথম ১৫ মিনিট—scope ও evidence: সন্দেহভাজন account, project, subscription, workload ও principal চিহ্নিত করুন। Process list, container state, active connection, instance metadata ও সংশ্লিষ্ট audit log export করুন; সম্ভব হলে workload বন্ধের আগে snapshot নিন এবং প্রতিটি পদক্ষেপের সময় লিখে রাখুন।
- ১৫–৬০ মিনিট—ক্ষমতাশালী access বন্ধ: exposed admin session, cloud access key, service-account key, federation token এবং refresh token disable বা revoke করুন। শুধু password বদলালে আগের session টিকে থাকতে পারে। জরুরি প্রশাসনিক access প্রয়োজন হলে পরিচ্ছন্ন device ও আলাদা break-glass identity ব্যবহার করুন।
- এক থেকে তিন ঘণ্টা—developer chain বিচ্ছিন্ন: CI/CD deploy key, repository personal-access token, package-registry token, webhook secret এবং infrastructure-as-code credential rotate করুন। যে credential নতুন token তৈরি করতে বা production deploy করতে পারে, সেটি আগে ঘোরান; আক্রান্ত build ও release সাময়িক স্থগিত রাখুন।
- তিন থেকে ছয় ঘণ্টা—egress ও persistence পরীক্ষা: আক্রান্ত workload isolate করুন, অপ্রয়োজনীয় outbound route এবং নতুন compute বা IP তৈরির permission সীমিত করুন। নতুন principal, scheduled task, image, SSH key, startup script ও অন্য persistence artifact খুঁজে পরিচ্ছন্ন environment থেকে প্রয়োজনীয় service পুনর্গঠন করুন।
Rotation শেষ হওয়া containment-এর প্রমাণ নয়। পুরোনো credential দিয়ে authentication ব্যর্থ হচ্ছে কি না, নতুন secret শুধু প্রত্যাশিত workload পাচ্ছে কি না এবং isolation-এর পর outbound scanning থেমেছে কি না—এই তিনটি ফল যাচাই করুন। Third-party credential জড়িত থাকলে সংশ্লিষ্ট provider বা partner-কে credential identifier, সম্ভাব্য exposure interval ও revocation status দ্রুত জানানো প্রয়োজন।
প্রকাশিত তথ্যের সীমা
আক্রান্ত প্রতিষ্ঠানের নাম, cloud provider, ব্যবহৃত AI coding chatbot বা model এবং compromise হওয়া credential-এর নির্দিষ্ট সংখ্যা ও ধরন প্রকাশ করা হয়নি। “হাজারো” credential-এর কতটি পরে অপব্যবহৃত হয়েছে, কতটি শুধু সংগ্রহ করা হয়েছিল কিংবা downstream intrusion কত দূর এগিয়েছিল—সেই তথ্যও নেই। তাই এই ঘটনা থেকে কোনো নির্দিষ্ট vendor বা model-এর দুর্বলতা প্রমাণিত হয় না।
এখন নিশ্চিতভাবে জানা যায়, compromised cloud foothold থেকে agent-assisted operation একই কর্মদিবসের মধ্যে scanning, troubleshooting, IP rotation ও mass credential compromise একসঙ্গে চালাতে পেরেছে। Initial-access path, victim scope এবং বিস্তারিত detection artifact প্রকাশ না হওয়া পর্যন্ত defender-এর মাপযোগ্য সীমা হলো এই ছয় ঘণ্টার observed campaign window—এটি সর্বজনীন deadline নয়, কিন্তু credential revocation পিছিয়ে দেওয়ার সুযোগ যে দ্রুত সংকুচিত হচ্ছে তার শক্ত প্রমাণ।
আরও পড়ুন:
আমাদের নিউজলেটার নিন
সর্বশেষ Web3, AI ও ক্রিপ্টো সংবাদ সরাসরি আপনার ইনবক্সে পান।