CWPdoor, cPGuard దాడులు: ట్రోజనైజ్డ్ సాఫ్ట్‌వేర్, హానికరమైన అప్‌డేట్‌ల ద్వారా Linux సర్వర్‌లే లక్ష్యం

బ్యాక్‌డోర్ చొప్పించిన ఒక Control Web Panel బైనరీ, హైజాక్ అయిన cPGuard అప్‌డేట్ ఛానల్ రెండూ వేర్వేరు ఘటనలు. హోస్టింగ్ అడ్మినిస్ట్రేటర్లకు ఒక్కొక్కటి ఏమి సూచిస్తుందో ఇక్కడ చూడండి.

Linux హోస్టింగ్ వాతావరణాలను ప్రభావితం చేస్తున్న రెండు ఘటనలు

2026 నవంబర్ మొదట్లో, Linux హోస్టింగ్ సర్వర్‌లను నిర్వహించడానికి, రక్షించడానికి వాడే టూల్స్‌కు సంబంధించిన రెండు వేర్వేరు సెక్యూరిటీ ఘటనలను పరిశోధకులు, వెండర్లు వెల్లడించారు. నవంబర్ 5న QiAnXin XLab, Control Web Panel (CWP) వాడే cwpsrv వెబ్ సర్వర్ బైనరీ యొక్క మార్పు చేసిన రూపంలో పొందుపరిచిన CWPdoor అనే బ్యాక్‌డోర్‌పై పరిశోధనను ప్రచురించింది. దీనితో సంబంధం లేకుండా, ఒక దాడిచేసే వ్యక్తి తమ ఇన్‌ఫ్రాస్ట్రక్చర్‌లోని ఒక భాగంలోకి చొరబడి, తమ cPGuard అప్‌డేట్ ఛానల్ ద్వారా నవంబర్ 2న ఒక హానికరమైన అప్‌డేట్‌ను పంపాడని OPSSHIELD నవంబర్ 3న వెల్లడించింది.

ఘటన	దాడి మార్గం	సెక్యూరిటీ ప్రభావం
CWPdoor	దాడిచేసేవారు అందించిన, అప్‌డేటర్‌లా కనిపించే ఒక స్క్రిప్ట్ cwpsrvను ట్రోజనైజ్డ్ బైనరీతో భర్తీ చేస్తుంది	దాచిన రిమోట్ కమాండ్ ఎగ్జిక్యూషన్
cPGuard	దొంగిలించిన అప్‌డేట్ పంపిణీ క్రెడెన్షియల్స్ వల్ల ఒక హానికరమైన అప్‌డేట్ కస్టమర్ సర్వర్‌లకు చేరుతుంది	root స్థాయి ఎగ్జిక్యూషన్, క్రెడెన్షియల్స్ బహిర్గతం, పర్సిస్టెన్స్ (persistence)

ఈ ఘటనలను ఒకే క్యాంపెయిన్‌గా గానీ, రాజీ పడిన ఒకే అప్‌డేట్ ఛానల్‌గా గానీ వర్ణించకూడదు. చట్టబద్ధమైన CWP వెండర్ అధికారిక అప్‌డేట్ ఇన్‌ఫ్రాస్ట్రక్చర్‌లోకి చొరబాటు జరిగిందని XLab నిర్ధారించలేదు. స్క్రిప్ట్ సర్వర్‌లకు ఎలా చేరుతుందో, ఏ వల్నరబిలిటీని వాడుతున్నారో తమకు తెలియదని XLab చెబుతోంది. cPGuard ఘటనలో మాత్రం OPSSHIELD పంపిణీ వ్యవస్థ నిజంగానే రాజీ పడింది. రెండింటికీ ఉన్న ఉమ్మడి అంశం ఆచరణాత్మకమైనది: రెండూ అధిక ప్రివిలేజ్‌తో నడిచే సాఫ్ట్‌వేర్ ద్వారా సర్వర్‌కు చేరతాయి, కాబట్టి రెండు సందర్భాల్లోనూ చేయాల్సింది ముందు బైనరీని ధృవీకరించడం, ఆ తర్వాత ఒక root ప్రాసెస్ చదవగలిగిన వాటిని రొటేట్ చేయడం.

CWPdoor: వెబ్ సర్వర్ పనిచేస్తూనే ఉంటుంది, లోపల బ్యాక్‌డోర్ దాగి ఉంటుంది

CWP సర్వర్ హోస్టింగ్ నిర్వహణ ఇంటర్‌ఫేస్‌ను అందిస్తుంది. దాని cwpsrv కాంపొనెంట్ మేనేజ్‌మెంట్ ట్రాఫిక్‌ను అందిస్తుంది. XLab ప్రకారం, దాని Cyber Threat Insight and Analysis System 2026 జూన్ 29న cwpsrv_update.sh అనే స్క్రిప్ట్‌ను పట్టుకుంది. ఈ స్క్రిప్ట్ 136.0.141[.]71 నుంచి cwpsrv అనే ఫైల్‌ను డౌన్‌లోడ్ చేసి, సిస్టమ్‌లో అదే పేరుతో ఉన్న ఫైల్‌ను భర్తీ చేస్తుంది. ఈ స్క్రిప్ట్ cwpsrv వెర్షన్‌లు 1.24.0, 1.15.10లను మాత్రమే సపోర్ట్ చేస్తుందని, దీన్ని root గా నడపాల్సి ఉంటుందని XLab చెబుతోంది.

XLab ఈ భర్తీ బైనరీని ఒక పాసివ్ బ్యాక్‌డోర్ (passive backdoor)గా వర్ణిస్తోంది. సాధారణ రిక్వెస్ట్‌లకు ఇది చట్టబద్ధమైన cwpsrvలాగే ప్రవర్తిస్తుంది, X-Ngx-Integrity-Time, X-Ngx-Integrity-Data, X-Ngx-Integrity-Sig అనే మూడు నిర్దిష్ట హెడర్‌లు ఉన్న రిక్వెస్ట్‌పై మాత్రమే చర్య తీసుకుంటుంది. టైమ్‌స్టాంప్ లేదా సిగ్నేచర్ తనిఖీ విఫలమైతే, ఆ రిక్వెస్ట్ సాధారణ ట్రాఫిక్‌గానే ముందుకు సాగుతుంది. లాగింగ్ మాడ్యూల్ ఆ రిక్వెస్ట్‌ను రికార్డ్ చేయకుండా ఉండేలా బ్యాక్‌డోర్ రిక్వెస్ట్ మాడ్యూల్ కాంటెక్స్ట్‌ను మార్చేస్తుందని, స్క్రిప్ట్ ఫైల్, డైరెక్టరీ టైమ్‌స్టాంప్‌లను పునరుద్ధరించి history -d నడుపుతుందని కూడా XLab చెబుతోంది. ఇది XLab ప్రకటన కాదు, TechiesJournal సొంత అనుమితి (inference): ప్యానెల్ పనిచేస్తూనే ఉంటుంది కాబట్టి, ఇలాంటి బ్యాక్‌డోర్‌ను అవైలబిలిటీ (availability) తనిఖీల ద్వారా గుర్తించడం కష్టం.

2026 సెప్టెంబర్ 30న బ్రెజిల్ నుంచి evidencia.tgz అనే ఫైల్ VirusTotalకు అప్‌లోడ్ అయిందని కూడా XLab నివేదిస్తోంది. అందులో XLab CWPdoorగా గుర్తించిన cwpsrv.suspeito ఫైల్ ఒక్క డిటెక్షన్ కూడా లేకుండా ఉంది, దాని పక్కనే చాలా వెండర్లు Ebury బ్యాక్‌డోర్‌గా గుర్తించిన ఒక శాంపిల్ కూడా ఉంది. నిజమైన బాధితులు ఉన్నారని XLab తేల్చింది, Ebury, CWPdoor మధ్య సంబంధం స్పష్టంగా లేదని చెబుతోంది.

XLab ఉదహరించిన QiAnXin Hunter Platform డేటా ప్రకారం, గత నెలలో 340,000కు పైగా CWP ఇన్‌స్టాన్స్‌లు ఇంటర్నెట్‌కు బహిర్గతమై ఉన్నాయి (XLab). ఇది బహిర్గతం (exposure) ను కొలుస్తుంది, నిర్ధారిత ఇన్‌ఫెక్షన్‌లను కాదు, ట్రోజనైజ్డ్ బైనరీ ఎన్ని సిస్టమ్‌లకు చేరిందో కూడా ఇది నిర్ధారించదు.

మూలం: QiAnXin XLab, CWPdoor.

cPGuard: విశ్వసనీయ సాఫ్ట్‌వేర్ అప్‌డేట్‌లే దాడి మార్గంగా మారాయి

OPSSHIELD నవంబర్ 3 వెల్లడి ప్రకారం, ఒక దాడిచేసే వ్యక్తి నవంబర్ 1, 2 తేదీల్లో దాని బిల్లింగ్, లైసెన్సింగ్ వాతావరణంలోకి ప్రవేశించి, అప్‌డేట్‌లను ప్రచురించడానికి వాడే కీలను తీసుకుని, నవంబర్ 2న ఒక నకిలీ cPGuard అప్‌డేట్‌ను అప్‌లోడ్ చేశాడు. cPGuard ఏజెంట్లు దాన్ని సుమారు 02:08 నుంచి 03:20 UTC మధ్య ఇన్‌స్టాల్ చేశాయని వెండర్ చెబుతోంది. ఒక సర్వర్ ప్రభావితం కాలేదని తేల్చడానికి ఆ సమయ వ్యవధిపై ఆధారపడవద్దు. OPSSHIELD అడ్వైజరీలోని ఉదాహరణ లాగ్ ఎంట్రీలలో ప్రభావిత వెర్షన్‌లు నవంబర్ 2న 12:46 వరకు ఇన్‌స్టాల్ అవుతూ కనిపిస్తున్నాయి, లాగ్ లేకపోవడం లేదా అసంపూర్ణంగా ఉండటం మాత్రమే ఒక సర్వర్ ప్రభావితం కాలేదని చూపించదని కూడా అడ్వైజరీ చెబుతోంది. మీకు సందేహం ఉంటే OPSSHIELD సపోర్ట్ బృందాన్ని సంప్రదించాలని అది సిఫారసు చేస్తోంది.

వెండర్ ప్రకారం, హానికరమైన స్క్రిప్ట్ root ప్రివిలేజ్‌లతో నడిచి, పాస్‌వర్డ్ హ్యాష్‌లు, SSH కీలు, MySQL క్రెడెన్షియల్స్, షెల్ హిస్టరీని సేకరించింది, వెనుక ఒక దాచిన root షెల్‌ను, ఒక షెడ్యూల్డ్ టాస్క్‌ను వదిలిపెట్టింది. దాడిచేసే వ్యక్తి ఎలా లోపలికి వచ్చాడనే విషయంలో OPSSHIELD రెండు పేజీలు భిన్నంగా చెబుతున్నాయి. నవంబర్ 1న నమోదైన ఒక కస్టమర్ ఖాతా ద్వారా బిల్లింగ్ అప్లికేషన్‌లోకి ప్రవేశం జరిగిందని, ఆ ఖచ్చితమైన రిక్వెస్ట్ తమ లాగ్‌లలో లేదని వెల్లడి చెబుతోంది. రాజీ పడిన క్రెడెన్షియల్స్‌ను వాడారని, అవి ఎలా దొరికాయో దర్యాప్తులో ఉందని అడ్వైజరీ చెబుతోంది.

వెండర్ నివేదించిన పరిశీలన	పరిధి
హానికరమైన అప్‌డేట్‌ను నడిపిన కస్టమర్ సర్వర్‌లు	సుమారు 2,950
కాపీ అయిన బిల్లింగ్ పోర్టల్ ఖాతా రికార్డులు	సుమారు 7,900
ప్రభావిత అప్‌డేట్ వెర్షన్‌లు (OPSSHIELD అడ్వైజరీ)	5.88.12 నుంచి 5.88.19 వరకు

బిల్లింగ్ ఖాతా పాస్‌వర్డ్‌లు bcrypt హ్యాష్‌లుగా నిల్వ అయ్యాయని OPSSHIELD చెబుతోంది. ఈ గణాంకాలు వెండర్ నివేదించిన ఘటన ఫలితాలు, ప్రతి సర్వర్ నుంచి సరిగ్గా ఏమి బయటకు తరలించారో స్వతంత్రంగా ధృవీకరించినవి కావు. సర్వర్ల సంఖ్య కూడా మారింది: దాడిచేసే వ్యక్తి సేకరించిన 32 ఫైల్‌లను తిరిగి పొందాడని OPSSHIELD మొదటి అడ్వైజరీ అంచనా వేసింది, దాన్ని నిర్ధారిత రిట్రీవల్‌కు సంబంధించిన ప్రాథమిక లెక్కగా పేర్కొంది, ప్రభావిత సర్వర్ల సంఖ్యగా కాదు. తర్వాత వచ్చిన వెల్లడి మాత్రం సుమారు 2,950 సర్వర్‌లు ఆ అప్‌డేట్‌ను నడిపాయని చెబుతోంది.

మూలాలు: OPSSHIELD ఘటన వెల్లడి (తాజాది), OPSSHIELD అడ్వైజరీ (మునుపటి ఫలితాలు).

cPGuard అడ్మినిస్ట్రేటర్లు ఏమి చేయాలి

cPGuard 5.88.25 లేదా ఆ తర్వాతి వెర్షన్ నడపాలని OPSSHIELD అడ్వైజరీ చెబుతోంది. దాని తర్వాతి వెల్లడి 5.88.26ను క్లీన్ రిలీజ్‌గా పేర్కొంటూ, మరో అప్‌డేట్ i93677 షెడ్యూల్డ్ టాస్క్‌ను తొలగిస్తుందని చెబుతోంది. తాజా వెర్షన్‌కు అప్‌డేట్ చేసి, ఆ తర్వాత కింద ఇచ్చిన ఫైల్‌లు తొలగిపోయాయని నిర్ధారించుకోండి. అడ్వైజరీ ఈ దశలను ఈ క్రమంలోనే ఇస్తుంది.

1. అప్‌డేట్ హిస్టరీని తనిఖీ చేయండి. 5.88.12 నుంచి 5.88.19 వరకు ఏ వెర్షన్ ఎంట్రీ ఉన్నా, ఆ సర్వర్ ప్రభావిత అప్‌డేట్‌ను ఇన్‌స్టాల్ చేసిందని అర్థం. ఇది ఇన్‌స్టాలేషన్‌ను మాత్రమే నిర్ధారిస్తుంది, ఏ ఫైల్‌లు బదిలీ అయ్యాయో కాదని, అలాంటి సర్వర్ ఇప్పుడు 5.88.25 లేదా ఆ తర్వాతి వెర్షన్ నడుపుతున్నా దాన్ని రాజీ పడి ఉండే అవకాశం ఉన్నదిగా పరిగణించాలని OPSSHIELD చెబుతోంది.

grep 'Successfully updated' /opt/cpguard/logs/install_log

2. అప్‌డేట్ చేయండి.

cpgcli update --start

3. వెర్షన్‌ను ధృవీకరించండి. OPSSHIELD అడ్వైజరీ 5.88.25 లేదా ఆ తర్వాతి వెర్షన్‌ను కోరుతుంది, అప్‌డేట్ విఫలమైతే సపోర్ట్‌ను సంప్రదించాలని చెబుతోంది.

cpgcli --version

4. మిగిలిపోయిన ఫైల్‌లు తొలగిపోయాయని నిర్ధారించుకోండి. వెల్లడి /etc/cron.d/i93677, /var/tmp/.i93677/, /var/tmp/.cpg91511_shలను పేర్కొంటుంది. అడ్వైజరీ /var/tmp/.cpg91511, /var/tmp/.cpg91511/loot.tgzలను జోడిస్తుంది. క్లీనప్ తర్వాత ఈ ఫైల్‌లు లేకపోవడం, స్క్రిప్ట్ ఇంతకుముందు నడిచిందో లేదో నిర్ధారించదని OPSSHIELD చెబుతోంది.

5. క్రెడెన్షియల్స్‌ను రొటేట్ చేయండి. క్లీన్ అప్‌డేట్ ఇప్పటికే కాపీ అయిన క్రెడెన్షియల్స్‌ను రద్దు చేయదు. ప్రభావితమై ఉండే అవకాశం ఉన్న సర్వర్‌ల అడ్మినిస్ట్రేటర్లు ఈ కింది చర్యలు తీసుకోవాలని OPSSHIELD కోరుతోంది:

• root పాస్‌వర్డ్‌ను, అన్ని లోకల్ ఖాతాల పాస్‌వర్డ్‌లను రీసెట్ చేయండి (అడ్వైజరీ ప్రకారం విశ్వసనీయ రికవరీ వాతావరణం నుంచి), ఇతర సిస్టమ్‌లలో మళ్లీ వాడిన పాస్‌వర్డ్‌లను విశ్వసనీయ పరికరం నుంచి మార్చండి.
• root SSH కీలను మార్చి, వాటిని విశ్వసించిన ప్రతి సిస్టమ్‌లోని authorized_keys నుంచి పాత పబ్లిక్ కీలను తొలగించండి. ఆ కీలతో చేరుకోగలిగే ఇతర సర్వర్‌లను, కీలు మార్చే వరకు బహిర్గతమైనవిగా పరిగణించండి.
• MySQL root పాస్‌వర్డ్‌ను, /root/.my.cnfలో నిల్వ ఉన్న డేటాబేస్ పాస్‌వర్డ్‌లను మార్చండి.
• root షెల్ హిస్టరీలో కనిపించిన పాస్‌వర్డ్‌లు, API కీలు, టోకెన్‌లను రొటేట్ చేయండి, వాటితో పాటు /root/.s3cfgలోని కీలను, ఏవైనా DigitalOcean టోకెన్‌లను కూడా రొటేట్ చేయండి (అడ్వైజరీ ఈ రెండింటినీ పేర్కొంటుంది).
• OPSSHIELD బిల్లింగ్ పోర్టల్ పాస్‌వర్డ్‌ను రీసెట్ చేసి, టూ ఫ్యాక్టర్ లాగిన్‌ను ఆన్ చేయండి. ఆ సమయ వ్యవధిలో cPGuard ఆఫ్‌లైన్‌లో ఉన్నా కూడా ఈ రీసెట్ చేయాలని వెల్లడి కోరుతోంది.
• దాడిచేసే వ్యక్తి మీ సర్వర్‌లోకి స్వయంగా (చేతితో) లాగిన్ అయ్యాడని OPSSHIELD మీకు చెప్పిన సందర్భంలో మాత్రమే, నవంబర్ 1కి ముందు తీసిన క్లీన్ బ్యాకప్ నుంచి సర్వర్‌ను పునర్నిర్మించండి. లేకపోతే అడ్వైజరీ సాధారణ పునర్నిర్మాణాన్ని సిఫారసు చేయదు, ఆ అంచనా తాత్కాలికమైనదని కూడా చెబుతోంది.

మరో రకం పరికరాల విషయంలో ఇదే రొటేషన్ సమస్యను ఫైర్‌వాల్ కాన్ఫిగరేషన్‌తో పాటు ఏమి బయటకు వెళ్తుంది, ఏమి రొటేట్ చేయాలి అనే TechiesJournal వ్యాసం వివరిస్తుంది. ప్యాచ్ చేసిన సిస్టమ్ తప్పనిసరిగా క్లీన్ సిస్టమ్ ఎందుకు కాదో ఎక్స్‌ప్లాయిట్ అయిన పరికరానికి ప్యాచ్ వేసిన తర్వాత ఏమి చేయాలి అనే మరో వ్యాసం వివరిస్తుంది.

CWP అడ్మినిస్ట్రేటర్లు ఏమి చేయాలి

XLab ఈ కింది హోస్ట్ తనిఖీలను ప్రచురిస్తోంది. CWPdoor ఇంటర్ ప్రాసెస్ కమ్యూనికేషన్ కోసం వాడే ngx_http_integrity_helper అనే Unix సాకెట్ కోసం మొదటి తనిఖీ వెతుకుతుంది.

ss -axp | grep integrity
ps aux | grep cwpsrv
strings /usr/local/cwpsrv/bin/cwpsrv | grep X-Ngx-Integrity

రెండో కమాండ్ విషయంలో, cwpsrvకి చెందిన అనుమానాస్పద helper చైల్డ్ ప్రాసెస్‌ల కోసం చూడాలని XLab చెబుతోంది. మూడో కమాండ్ విషయంలో, బైనరీలో అనుమానాస్పద X-Ngx-Integrity స్ట్రింగ్‌ల కోసం చూడాలని చెబుతోంది. నెట్‌వర్క్ బృందాలు 136.0.141[.]71కు జరిగిన కనెక్షన్‌ల కోసం ఫైర్‌వాల్, ప్రాక్సీ లాగ్‌లను కూడా వెతకవచ్చు. XLab డౌన్‌లోడర్‌గా పేర్కొన్న చిరునామా ఇదే.

ఇన్‌ఫెక్షన్ నిర్ధారణ అయితే, XLab మూడు దశలను సిఫారసు చేస్తుంది. మొదటిది, హానికరమైన cwpsrvను, దాడిచేసే వ్యక్తి స్క్రిప్ట్ /usr/local/cwpsrv/binలో సృష్టించిన చట్టబద్ధమైన బ్యాకప్‌తో భర్తీ చేయడం. ఆ బ్యాకప్ పేరు cwpsrv.prev- తర్వాత ఒక టైమ్‌స్టాంప్. రెండోది, తాజా వెర్షన్‌కు అప్‌గ్రేడ్ చేసి, ss -axp | grep integrity ఇక ఏ మ్యాచ్‌నూ చూపించడం లేదని నిర్ధారించుకోవడం. మూడోది, అన్ని కంట్రోల్ ప్యానెల్ క్రెడెన్షియల్స్‌ను వెంటనే రొటేట్ చేసి వాటిని రాజీ పడినవిగా పరిగణించడం, హోస్ట్‌ను కూడా రాజీ పడినదిగా పరిగణించి ఇతర ముప్పుల కోసం దర్యాప్తు చేయడం.

భర్తీ విజయవంతమైనప్పుడు స్క్రిప్ట్ తన బ్యాకప్‌ను తొలగిస్తుందని కూడా XLab చెబుతోందని గమనించండి, కాబట్టి ఆ cwpsrv.prev- ఫైల్ ఉండకపోవచ్చు. TechiesJournal అనుమితి ఏమిటంటే, విశ్వసనీయ CWP మూలం నుంచి పొందిన బైనరీయే మరింత సురక్షితమైన భర్తీ. బ్యాక్‌డోర్ ఏ కమాండ్‌నైనా నడపగలదు కాబట్టి హోస్ట్‌ను రాజీ పడినదిగా పరిగణించాలని XLab కోరుతోంది, అందువల్ల బైనరీని మాత్రమే భర్తీ చేయడం సరిపోదు.

మూలం: QiAnXin XLab, CWPdoor.

అడ్మినిస్ట్రేటర్లు గుర్తుంచుకోవాల్సింది

ఇంకా పనిచేస్తున్నట్లే కనిపించే సాఫ్ట్‌వేర్ లోపల, మార్పు చేసిన ఒక ఎగ్జిక్యూటబుల్ రిమోట్ యాక్సెస్‌ను ఎలా దాచగలదో CWPdoor చూపిస్తుంది. చట్టబద్ధమైన అప్‌డేట్ పంపిణీ మార్గానికి దాడిచేసే వ్యక్తి యాక్సెస్ పొందడం అనే వేరే ప్రమాదాన్ని cPGuard ఘటన చూపిస్తుంది. ఆచరణలో ఏమి చేయాలనేది హోస్ట్‌ను ఏ ఘటన ప్రభావితం చేసిందనే దానిపై ఆధారపడి ఉంటుంది: ఇన్‌స్టాల్ అయిన బైనరీలను, అప్‌డేట్ హిస్టరీని ధృవీకరించండి, రాజీ పడిన కాంపొనెంట్‌లను భర్తీ చేయండి, పర్సిస్టెన్స్ కోసం దర్యాప్తు చేయండి, బహిర్గతమైన క్రెడెన్షియల్స్‌ను రొటేట్ చేయండి.

మూలాలు

• QiAnXin XLab: CWPdoor పరిశోధన, 2026 నవంబర్ 5
• OPSSHIELD ఘటన వెల్లడి (తాజాది), 2026 నవంబర్ 3
• OPSSHIELD అడ్వైజరీ (మునుపటి ఫలితాలు), 2026 నవంబర్ 3

మూలాలను 2026 నవంబర్ 12న చదివాము. OPSSHIELD తన వెల్లడిని అప్‌డేట్ చేస్తూనే ఉంటామని చెబుతోంది, కాబట్టి చర్య తీసుకునే ముందు దాన్ని తనిఖీ చేయండి.