Incident kompanije Binance od 6,3 milijarde dolara: šta se dogodilo i kako smanjiti rizik

Rast proizvoda u Semaphore UI
12 min čitanja

Kompromitovan računar zaposlenog može da ugrozi mnogo više od lokalnih datoteka. Analiziramo napad na Binance i pokazujemo kako kontrolisana automatizacija pomoću Semaphore UI može da ograniči čemu napadač može da pristupi, šta može da promeni i šta može da nastavi da koristi.

Razgovarajte o članku sa AI

Pregled

Dana 29. oktobra 2026. napadači su pristupili sistemima kompanije Binance za potpisivanje transakcija novčanika. U svom preliminarnom izveštaju od 3. novembra, Binance je procenio pogođenu imovinu na približno 6,34 milijarde američkih dolara, od čega je 2,85 milijardi zamrznuto ili presretnuto. Upad je počeo na računarima zaposlenih.

Takav početak poznat je i daleko van sveta kriptovaluta. Kompromitovana radna stanica može da izloži produkcione akreditive, prava za postavljanje softvera i interne alate koji otvaraju put do uređaja drugih zaposlenih. Inženjerski izazov je sprečiti da ta ovlašćenja pretvore jedan kompromitovan nalog u kontrolu nad kritičnim servisom.

Kako se napad odvijao

Preliminarni nalazi kompanije Binance opisuju kompromitovanje zaposlenih u junu i septembru, a zatim širi upad preko internih AI alata 20. oktobra. Napadači su pristupili računarima dvojice kolega i pronašli token za postavljanje kontejnera. Dana 29. oktobra iskoristili su ga da postave zlonamerni kod koji je pristupio sistemima za potpisivanje transakcija novčanika i pokrenuo neovlašćene prenose.

  1. Izmenjen Homebrew instalacioni program

    Binance je zamenio uređaj i rotirao akreditive. Napadač je saznao ulogu inženjera i njegove kolege.

  2. Zlonamerni zadatak za intervju

    Zlonamerni repozitorijum omogućio je napadačima uporište na računaru drugog zaposlenog.

  3. Dobijen token za postavljanje

    Interni AI alati pomogli su napadačima da pristupe kolegama i pronađu token.

  4. 17:15–19:56 UTC

    Postavljen zlonamerni kontejner

    Ukradeni token za postavljanje omogućio je zlonamernom kodu pristup sistemima za potpisivanje transakcija novčanika.

  5. 20:05–20:09 UTC

    Počinju neovlašćeni prenosi

  6. 23:56 UTC

    Potvrđen poslednji neovlašćeni prenos

  7. 00:10 UTC

    Opozvana Ethereum delegacija

    Dozvola na blokčejnu zahtevala je zasebno opozivanje.

Tok incidenta kompanije Binance, 2026. Sva vremena su prikazana u UTC-u.

Napadači su upotrebili i servis za potpisivanje da naprave EIP-7702 delegaciju: dozvolu da kod pod njihovom kontrolom deluje u ime Ethereum novčanika. Ta dozvola je postojala na blokčejnu, nezavisno od sistema kompanije Binance za povlačenje sredstava. Obustava povlačenja nije mogla da je ukloni. Binance je morao zasebno da je opozove na samom blokčejnu.

Važno je razlikovati zaustavljanje aktivnosti od uklanjanja ovlašćenja koje je omogućava. Zamena uređaja, opozivanje akreditiva za postavljanje i ukidanje dozvole u drugom sistemu rešavaju različite delove upada.

Šta incident otkriva o bezbednosti produkcije

Laptop, sistem za postavljanje i osetljiv servis obavljaju različite poslove. Rizik raste kada pristup jednom automatski otvara sledeći. Ukradeni token može napadaču da omogući zamenu softvera. Taj softver zatim može da deluje sa ovlašćenjima koja zaposleni nikada nije imao direktno.

Četiri pitanja pomažu da se utvrdi gde treba prekinuti taj sled:

  1. Izloženost akreditiva. Kakav pristup produkciji napadač može da dobije sa uređaja jednog zaposlenog?
  2. Ovlašćenja za postavljanje. Ko može da menja kod koji se izvršava sa tim pristupom?
  3. Autorizacija u servisu. Koje radnje će osetljiv servis prihvatiti od tog koda?
  4. Trajan pristup. Koje nove dozvole mogu da ostanu nakon što se prvobitni nalog onemogući?

Cilj je da se ograniči prenošenje ovlašćenja između sistema i pronađe i opozove svaki dodatni pristup nastao tokom upada. U narednim odeljcima razmatramo četiri kontrole koje podržavaju taj cilj.

Kompromitovan laptop

Napadač kontroliše uređaj

1Ograničite akreditive
Token za postavljanje
Sistem za postavljanje

Prihvata izmenu softvera

2Zaštitite izmene
Zlonamerni kod
Aktivno radno opterećenje

Kod nasleđuje njegova ovlašćenja

Servisni identitet
Osetljiv servis

Izvršava privilegovane zahteve

3Autorizujte zahteve
4
Obuzdavanje i opozivanje

Identifikujte i opozovite nove akreditive i dozvole u svim pogođenim sistemima.
Ukradeni token može da odobri novi kod, koji zatim koristi ovlašćenja radnog opterećenja. Kontrole 1–3 ograničavaju taj put. Kontrola 4 odnosi se na pristup stvoren bilo gde tokom upada.

Kontrola 1. Smanjite broj akreditiva koje laptop može da izloži

Akreditiv je koristan napadaču zato što ga drugi sistem prihvata kao dokaz ovlašćenja. Ako se na uređajima zaposlenih nalazi manje produkcionih akreditiva, manje toga može da se ukrade kada se kompromituje alat, repozitorijum ili sesija pregledača.

Za rutinski posao zaposlenom je često potrebna dozvola da zatraži operaciju, kao što je ponovno pokretanje servisa. Akreditiv koji je izvršava može da ostane kod zasebnog izvršnog identiteta. Smanjenje izloženosti podrazumeva uklanjanje nepotrebnih kopija i upravljanje akreditivima koji ostaju:

  • Gde je izvodljivo, zamenite rutinski direktan pristup usko definisanim operacijama.
  • Koristite odvojene identitete za različite dužnosti i ograničite njihov opseg i vek trajanja.
  • Vodite evidenciju akreditiva, njihovih vlasnika i postupka opozivanja.

Time se primenjuje načelo iz smernica organizacije OWASP za upravljanje tajnama: smanjite ljudsko rukovanje tajnama i svakom identitetu dodelite samo potreban pristup. Ukradena radna stanica tada izlaže manje akreditiva koji se mogu ponovo koristiti, a tim za odgovor zna ko je odgovoran za one koje još treba opozvati.

Kontrola 2. Prava za postavljanje tretirajte kao produkciona ovlašćenja

Tajna može biti skrivena od osobe, ali dostupna kodu koji ona postavlja. Onaj ko može da menja taj kod možda može da pročita tajnu, pozove interni API ili deluje kao servisni nalog aplikacije. Zato pristup za postavljanje treba procenjivati prema ovlašćenjima radnog opterećenja koje će se izvršavati.

Smernice organizacije OWASP za CI/CD bezbednost posmatraju izmene repozitorijuma, konfiguraciju pipeline-a i izvršne hostove kao delove istog bezbednosnog problema. Zaštita mora da obuhvati kod pre postavljanja i njegova ovlašćenja nakon postavljanja:

  • Zahtevajte pregled produkcionog koda i zaštitite granu repozitorijuma koju automatizacija izvršava.
  • Kontrolišite izmene definicija zadataka, zavisnosti i ulaznih podataka pri pokretanju, kao i glavne skripte.
  • Radnim opterećenjima dodelite samo akreditive i mrežni pristup potrebne za njihovu funkciju.

Dva skupa kontrola moraju da rade zajedno. Dozvole za repozitorijum i postavljanje određuju ko može da menja kod. Zasebne politike identiteta, hostova i mreže ograničavaju šta taj kod može da uradi kada se pokrene. Centralno skladište tajni smanjuje izloženost, dok te politike ograničavaju program koji tajnu koristi.

Kontrola 3. Autorizujte operaciju, a ne samo pozivaoca

Servis za potpisivanje može da čuva privatni ključ skrivenim, a da ipak prihvati štetan zahtev za potpisivanje. Ista razlika važi za bazu podataka ili cloud API: autentifikacija radnog opterećenja utvrđuje ko je pozivalac, dok autorizacija određuje šta sme da uradi.

OWASP preporučuje proveru autorizacije pri svakom zahtevu i odbijanje pristupa ako nije izričito dozvoljen. U servisu koji prima zahtev to znači proveru radnje i njenog cilja: dozvoljenih odredišta i iznosa uplata, operacija nad bazom podataka ili izmena infrastrukture.

Rezultat treba da bude servis koji procenjuje traženu radnju čak i kada pozivaocu već veruje. Automatizacija određuje kako se posao traži. Odredišni servis određuje koje operacije će prihvatiti.

Kontrola 4. Opozovite pristup nastao tokom upada

Napadač može da upotrebi legitiman identitet da doda drugi akreditiv ili dodeli dodatne dozvole. MITRE ATT&CK dokumentuje manipulaciju nalozima kao način zadržavanja ili povećavanja pristupa, uključujući dodavanje cloud akreditiva i SSH ključeva. Onemogućavanje prvobitne sesije ne uklanja nužno te izmene.

Delegacija kompanije Binance na blokčejnu pokazuje zašto tim za odgovor mora da proveri dozvole u samom pogođenom sistemu. Obuzdavanje incidenta mora da obuhvati i početno uporište i ovlašćenja stvorena preko njega:

  • Ograničite koji identiteti automatizacije mogu da stvaraju dodatne akreditive ili dodeljuju dozvole.
  • U plan odgovora uključite novonapravljene naloge, sesije i delegacije.
  • Proverite opozivanje u sistemu koji sprovodi dozvolu, umesto da zaustavljen zadatak smatrate dokazom obuzdavanja incidenta.

Ovi koraci daju timu za odgovor definisan skup identiteta i dozvola koje treba istražiti i opozvati. Time obuzdavanje postaje proverljivo: tim može da utvrdi da li je svaki poznati put do pogođenog servisa zaista zatvoren.

Te kontrole deluju na različitim slojevima: uređaju zaposlenog, sistemu za postavljanje, odredišnom servisu i procesu odgovora. Svaki sloj mora da ima odgovornu osobu i način provere da njegova ograničenja važe i kada je drugi sloj kompromitovan.

Kako pomaže kontrolisana automatizacija

Platforme za upravljanje automatizacijom rešavaju deo ovog problema između zahteva zaposlenog i izvršavanja u produkciji. U Semaphore UI tim može da pripremi definisan zadatak, odredi ko sme da ga pokrene ili izmeni i izvrši ga pomoću zasebnog identiteta. Autorizacija u odredišnom servisu i opozivanje dozvola nastalih drugde ostaju odgovornost tih sistema i tima za odgovor.

Zamislite dežurnog inženjera koji treba ponovo da pokrene API servis. Održavalac priprema playbook i Task Template koji određuju ciljne hostove i način ponovnog pokretanja. Inženjer pokreće zadatak i čita rezultat, bez otvaranja SSH sesije u produkciji. Dva puta prikazana ispod obavljaju isto ponovno pokretanje, ali poveravaju izvršni akreditiv različitim stranama.

Direktan pristup

Laptop zaposlenog Čuva produkcioni ključ
Direktan SSH pristup
Produkcioni host

Servis se ponovo pokreće

Kompromitovan laptop može da izloži produkcioni akreditiv koji se može ponovo koristiti.

Preko Semaphore UI

Laptop zaposlenog

Dozvola da pokrene sačuvan zadatak

Zahtevaj zadatak
Granica izvršavanja Semaphore server ili runner Koristi ključ ograničenog opsegaKey Store ili spoljno skladište tajni
Izvrši operaciju
Produkcioni host

Servis se ponovo pokreće

U ovoj konfiguraciji izvršni ključ ne nalazi se na uređaju zaposlenog. Ukradena sesija i dalje može da pokrene dozvoljene zadatke.

Jedno ponovno pokretanje, dva modela pristupa: direktni produkcioni akreditivi ili dozvola za pokretanje kontrolisanog zadatka.

Izrada toka za ponovno pokretanje ima četiri povezana koraka: napraviti ograničen izvršni identitet, definisati šta korisnici mogu da pokreću ili menjaju, odabrati izvršno okruženje i učiniti rezultat vidljivim. Kada su ti koraci završeni, isti pristup može da se proširi na postavljanje softvera.

Korak 1. Napravite ograničen izvršni identitet

Počnite od ciljnih hostova. Napravite nalog za automatizaciju čiji je privilegovani pristup ograničen na ponovno pokretanje API servisa. Ne treba da može da menja definiciju servisa niti da izvršava nepovezane privilegovane komande. Za preuzimanje repozitorijuma sa playbook-om koristite zaseban akreditiv koji ima samo pravo čitanja. Ta ograničenja određuju šta automatizacija može da uradi čak i ako se njen akreditiv zloupotrebi.

U projektnom Key Store-u registrujte SSH akreditiv i odaberite ga u produkcionom inventaru koji navodi ciljne hostove. Odaberite lokalnu bazu podataka za skladištenje ili referencu na zaštićenu serversku datoteku ili promenljivu okruženja. Za lokalno skladištenje podesite ključeve za šifrovanje i čuvajte ključni materijal odvojeno od rezervnih kopija baze podataka.

Ako tim već koristi podržano skladište tajni, kao što je OpenBao u Pro izdanju ili AWS Secrets Manager u Enterprise izdanju, registrujte ga pod Key Store → Storages i pri kreiranju ključa referencirajte postojeću tajnu. Ograničite integraciju na tajne potrebne ovom toku. Operater tada može da zatraži ponovno pokretanje bez preuzimanja izvršnog akreditiva.

Korak 2. Definišite šta operater može da pokrene ili izmeni

Zatim sačuvajte šablon “Restart API” sa pregledanim playbook-om, produkcionim inventarom i potrebnim promenljivama. Izmene tih resursa prepustite održavaocima. Za operatere odaberite projektnu ulogu koja dozvoljava izvršavanje bez uređivanja: ugrađena uloga Task Runner može da pokrene svaki šablon u tom projektu, pa svi moraju biti odgovarajući za tu grupu.

Za pristup odabranim šablonima koristite prilagođene uloge i dozvole za šablone u Enterprise izdanju, uz osnovnu ulogu koja već ne dozvoljava izvršavanje u celom projektu. Te dozvole se sabiraju, pa dodeljivanje uske prilagođene uloge ne poništava šira ovlašćenja koja korisnik već ima.

Tako se ta razlika može sprovesti: operateri mogu da zatraže pripremljeno ponovno pokretanje, dok održavaoci kontrolišu kod, ciljeve i akreditive koji ga omogućavaju. Testirajte zbirne dozvole sa nalogom operatera pre nego što dodelite pristup produkciji.

Korak 3. Izvršavajte zadatke na ograničenom runner-u

Instalirajte udaljeni runner na namenski host koji može da pristupi API serverima. Kada operater pokrene “Restart API”, runner izvršava playbook i vraća izlaz Semaphore-u. Zaposlenima je potreban pristup Semaphore-u, dok pravila zaštitnog zida mogu da ograniče vezu za upravljanje produkcijom na runner.

Tom izvršnom hostu dodelite samo pristup potreban za njegove zadatke:

  • Odvojite izvršavanje u produkciji od manje pouzdanih radnih opterećenja i razvojnih okruženja.
  • Ograničite ovlašćenja runner-a u operativnom sistemu, izlazne veze i montirane akreditive. Zaštitite njegov token za autentifikaciju i koristite HTTPS sa proverom sertifikata za povezivanje sa Semaphore-om.
  • Koristite oznake runner-a u Pro izdanju, kao što je production, da usmerite šablon na predviđene runner-e. Mrežna ograničenja sprovodite na tim hostovima.

Time se sužava gde produkcioni akreditivi mogu da se koriste i kojim sistemima zadatak može da pristupi. Runner nije automatski sandbox: njegovi zadaci mogu da koriste datoteke, akreditive i mrežu dostupne svom procesu. Odvojite produkciono izvršavanje od nepouzdanih poslova i bezbednosno ojačajte i redovno ažurirajte i runner i Semaphore server.

Korak 4. Pregledajte izvršavanje i učinite zloupotrebu vidljivom

Nakon ponovnog pokretanja operater otvara rezultat zadatka da proveri status, izlaz i reviziju repozitorijuma. U playbook uključite proveru ispravnosti servisa, kako bi rezultat pokazao da li se API oporavio, a ne samo da li je komanda za ponovno pokretanje uspešno završena. Ne dozvolite da se tajne pojave u tom izlazu.

Podesite obaveštenja o rezultatima zadataka za kanal koji dežurni tim prati i dogovorite ko istražuje neočekivana izvršavanja. Uspešan zadatak i dalje može biti neovlašćena aktivnost. Tokom istrage povežite zapis o izvršavanju sa logovima hostova, provajdera identiteta i skladišta tajni da biste videli kako je pristup dobijen i upotrebljen.

Tim sada ima zajednički zapis o traženoj operaciji i njenom ishodu. To olakšava istragu neuobičajenih aktivnosti, pod uslovom da ih neko prati i ima jasan postupak odgovora.

Primena istih kontrola na postavljanje softvera

Postavljanje koristi isti model pristupa, ali i instalira softver. Napravite zaseban šablon “Deploy API” sa identitetom za postavljanje čija su ovlašćenja ograničena na tu aplikaciju. Njegova konfiguracija mora da ograniči i kod koji obavlja postavljanje i izdanje koje instalira:

  • Fiksirajte kod za postavljanje i cilj. Koristite deploy_api.yml iz zaštićene grane main i inventar production-api. Isključite unos grane, inventara i CLI argumenata pri pokretanju.
  • Izmene prepustite održavaocima. Operateri mogu da pokrenu šablon, dok održavaoci kontrolišu njegov kod, akreditive i konfiguraciju.
  • Proverite izbor izdanja u playbook-u. Proverite svaku promenljivu pri pokretanju koja može da utiče na izdanje. Dozvoljeni identifikator izdanja povežite sa nepromenljivim artefaktom iz pouzdanog procesa izgradnje i proverite njegovo poreklo i integritet pre postavljanja. Odbijte proizvoljne reference na slike kontejnera i neprepoznate ulazne podatke.

Te kontrole ograničavaju šta ukradena sesija operatera može da postavi. Semaphore sprovodi pristup zadacima. Pregled u Git-u i playbook ograničavaju kod i artefakte. Dozvola za izmenu tog playbook-a ostaje produkciono ovlašćenje.

Bilo da zadatak ponovo pokreće servis ili postavlja izdanje, operater dobija rezultat bez dobijanja izvršnog akreditiva. Tim sada može da testira razliku koja je važna: koje su produkcione radnje i dalje moguće kroz sesiju tog operatera?

Šta ukradena sesija i dalje može da uradi

Ukradena sesija operatera i dalje može da zahteva operacije koje taj nalog sme da pokreće. Čak i dozvoljeno ponovno pokretanje može da prekine servis ako se stalno ponavlja. Testirajte podešeni tok sa realističnim nalogom operatera u staging okruženju, obuhvatajući i njegove mogućnosti i način na koji bi tim reagovao na zloupotrebu:

  • Dozvole za zadatke i ulazne podatke. Isprobajte stvarne uloge i opcije pri pokretanju, uključujući druge grane, inventare i argumente.
  • Pristup izvan predviđene operacije. Proverite pristup drugim šablonima, akreditivima i produkcionim sistemima, uključujući ono čemu proces runner-a može da pristupi.
  • Otkrivanje i operativni uticaj. Potvrdite ko prima rezultate, ko istražuje neočekivane aktivnosti i da li ponovljena izvršavanja mogu da izazovu neprihvatljive prekide.
  • Opozivanje. Testirajte opozivanje sesija i tokena i identifikujte dozvole koje bi izvršni identitet mogao da napravi drugde.

Dokumentujte pristup koji testni nalog zadržava i zatvorite svaki put koji prevazilazi svrhu operacije. Tim treba da završi vežbu znajući i šta bi ukradena sesija mogla da uradi i kako da otkrije i obuzda takvu zloupotrebu.

Bezbednost u svakodnevnom radu

Kontrole pristupa deluju zajedno sa zaštitom krajnjih uređaja i timom koji zna kako da reaguje. Neka pripremljeni tok bude dovoljno praktičan da ljudi mogu da ga koriste bez povratka zajedničkim ključevima i nedokumentovanim prečicama. Podržite ga sa nekoliko svakodnevnih praksi:

  • Nepoznate instalacione programe i zadatke za intervjue pokrećite u jednokratnim, izolovanim okruženjima bez korporativnih akreditiva, montiranih direktorijuma hosta ili pristupa internim mrežama.
  • Olakšajte rano prijavljivanje sumnjivih aktivnosti bez okrivljavanja. Obezbedite jasan kontakt i postupak odgovora na incident.
  • Proveravajte pristup pri promeni dužnosti, održavajte kontrolisan postupak hitnog pristupa i uvežbavajte opozivanje pre incidenta.

Te prakse povezuju prevenciju, otkrivanje i oporavak sa svakodnevnim radom. Pomažu da model pristupa ostane tačan kako se odgovornosti menjaju i daju timu poznat način reagovanja na sumnjiv događaj.

Ograničite domet sledećeg kompromitovanja

Glavna pouka je da treba ograničiti koliko ovlašćenja jedan kompromitovan identitet može da prikupi. Manje akreditiva na laptopovima, pregledana automatizacija, ograničeni izvršni hostovi i autorizacija u produkcionim servisima smanjuju puteve kojima napadač može da krene.

Semaphore pretvara nekoliko tih kontrola u ponovljiv radni tok: pripremljeni zadaci, odvojene dozvole za pokretanje i uređivanje, centralno obezbeđeni akreditivi i vidljivi zapisi o izvršavanju. Operateri dobijaju radnje potrebne za svoj posao, dok održavaoci zadržavaju kontrolu nad kodom i akreditivima koji ih omogućavaju.

Počnite od jedne često korišćene produkcione operacije: pripremite njen šablon zadatka, dodelite potrebne dozvole operatera i testirajte dobijeni pristup pre nego što ukinete direktnu vezu koju zamenjuje. Korisno merilo napretka je koliko malo napadač može da uradi sa sledećim nalogom koji kompromituje.

Izvori

  1. Binance, “29 October 2026 Binance Security Incident: Initial Findings and Response Update”. URL: https://www.binance.com/en/blog/community/3229153443759566763 (pristupljeno: ).
  2. OWASP Foundation, “Secrets Management Cheat Sheet”. URL: https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html (pristupljeno: ).
  3. OWASP Foundation, “CI/CD Security Cheat Sheet”. URL: https://cheatsheetseries.owasp.org/cheatsheets/CI_CD_Security_Cheat_Sheet.html (pristupljeno: ).
  4. OWASP Foundation, “Authorization Cheat Sheet”. URL: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html (pristupljeno: ).
  5. MITRE ATT&CK, “Account Manipulation (T1098)”. URL: https://attack.mitre.org/techniques/T1098/ (pristupljeno: ).
  6. Semaphore UI, “Task Templates”. URL: https://semaphoreui.com/docs/user-guide/task-templates (pristupljeno: ).
  7. Semaphore UI, “Key Store”. URL: https://semaphoreui.com/docs/user-guide/key-store (pristupljeno: ).
  8. Semaphore UI, “Inventory”. URL: https://semaphoreui.com/docs/user-guide/inventory (pristupljeno: ).
  9. Semaphore UI, “Encryption Keys”. URL: https://semaphoreui.com/docs/admin-guide/security/encryption (pristupljeno: ).
  10. Semaphore UI, “AWS Secrets Manager secret storage”. URL: https://semaphoreui.com/docs/user-guide/key-store/aws-secrets-manager (pristupljeno: ).
  11. Semaphore UI, “Teams”. URL: https://semaphoreui.com/docs/user-guide/team (pristupljeno: ).
  12. Semaphore UI, “Runners”. URL: https://semaphoreui.com/docs/admin-guide/runners (pristupljeno: ).
  13. Semaphore UI, “Tasks”. URL: https://semaphoreui.com/docs/user-guide/tasks (pristupljeno: ).
  14. Semaphore UI, “Alerts”. URL: https://semaphoreui.com/docs/user-guide/alerts (pristupljeno: ).