Drive-by Compromise

Adversaries may gain access to a system through a user visiting a website over the normal course of browsing. With this technique, the user's web browser is typically targeted for exploitation, but adversaries may also use compromised websites for non-exploitation behavior such as acquiring Application Access Token.

Multiple ways of delivering exploit code to a browser exist, including:

A legitimate website is compromised where adversaries have injected some form of malicious code such as JavaScript, iFrames, and cross-site scripting.
Malicious ads are paid for and served through legitimate ad providers.
Built-in web application interfaces are leveraged for the insertion of any other kind of object that can be used to display web content or contain a script that executes on the visiting client (e.g. forum posts, comments, and other user controllable web content).

Often the website used by an adversary is one visited by a specific community, such as government, a particular industry, or region, where the goal is to compromise a specific user or set of users based on a shared interest. This kind of targeted attack is referred to a strategic web compromise or watering hole attack. There are several known examples of this occurring.^[1]

Typical drive-by compromise process:

A user visits a website that is used to host the adversary controlled content.
Scripts automatically execute, typically searching versions of the browser and plugins for a potentially vulnerable version.
- The user may be required to assist in this process by enabling scripting or active website components and ignoring warning dialog boxes.
Upon finding a vulnerable version, exploit code is delivered to the browser.
If exploitation is successful, then it will give the adversary code execution on the user's system unless other protections are in place.
- In some cases a second visit to the website after the initial scan is required before exploit code is delivered.

Unlike Exploit Public-Facing Application, the focus of this technique is to exploit software on a client endpoint upon visiting a website. This will commonly give an adversary access to systems on the internal network instead of external systems that may be in a DMZ.

Adversaries may also use compromised websites to deliver a user to a malicious application designed to Steal Application Access Tokens, like OAuth tokens, to gain access to protected applications and information. These malicious applications have been delivered through popups on legitimate websites.^[2]

Angreifer können sich Zugang zu einem System verschaffen, indem ein Benutzer eine Website besucht, während er normal surft. Bei dieser Technik wird in der Regel der Webbrowser des Benutzers für einen Angriff missbraucht, aber Angreifer können kompromittierte Websites auch für andere Zwecke nutzen, z. B. für den Erwerb von Application Access Token.

Es gibt mehrere Möglichkeiten, Exploit-Code an einen Browser zu übermitteln, darunter:

Eine legitime Website wird kompromittiert, in die die Angreifer eine Form von bösartigem Code wie JavaScript, iFrames und Cross-Site-Scripting eingefügt haben.
Bösartige Werbung wird über legitime Werbeanbieter bezahlt und geschaltet.
Integrierte Webanwendungsschnittstellen werden für das Einfügen anderer Objekte genutzt, die zur Anzeige von Webinhalten verwendet werden können oder ein Skript enthalten, das auf dem besuchenden Client ausgeführt wird (z. B. Forenbeiträge, Kommentare und andere vom Benutzer steuerbare Webinhalte).

Oft ist die von einem Angreifer genutzte Website eine, die von einer bestimmten Gemeinschaft besucht wird, z. B. von einer Regierung, einer bestimmten Branche oder einer Region, wobei das Ziel darin besteht, einen bestimmten Benutzer oder eine bestimmte Gruppe von Benutzern auf der Grundlage eines gemeinsamen Interesses zu kompromittieren. Diese Art von gezieltem Angriff wird als strategische Webkompromittierung oder Watering Hole-Angriff bezeichnet. Es gibt mehrere bekannte Beispiele für solche Angriffe (Zitat: Shadowserver Strategic Web Compromise)

Typischer Drive-by-Kompromittierungsprozess:

Ein Benutzer besucht eine Website, die als Host für die vom Gegner kontrollierten Inhalte dient.
Skripte werden automatisch ausgeführt und durchsuchen in der Regel die Versionen des Browsers und der Plugins nach einer potenziell anfälligen Version.
- Der Benutzer kann aufgefordert werden, diesen Prozess zu unterstützen, indem er Skripte oder aktive Website-Komponenten aktiviert und Warndialogfelder ignoriert.
Wenn eine anfällige Version gefunden wird, wird der Exploit-Code an den Browser übermittelt.
Wenn die Ausnutzung erfolgreich ist, kann der Angreifer den Code auf dem System des Benutzers ausführen, es sei denn, es sind andere Schutzmechanismen vorhanden.
- In einigen Fällen ist ein zweiter Besuch der Website nach dem ersten Scan erforderlich, bevor der Exploit-Code ausgeliefert wird.

Im Gegensatz zu Exploit Public-Facing Application liegt der Schwerpunkt dieser Technik auf der Ausnutzung von Software auf einem Client-Endpunkt beim Besuch einer Website. Dadurch erhält ein Angreifer in der Regel Zugriff auf Systeme im internen Netzwerk und nicht auf externe Systeme, die sich möglicherweise in einer DMZ befinden.

Angreifer können auch kompromittierte Websites nutzen, um einen Benutzer zu einer bösartigen Anwendung zu leiten, die darauf abzielt, Steal Application Access Tokens, wie OAuth-Tokens, zu stehlen, um Zugang zu geschützten Anwendungen und Informationen zu erhalten. Diese bösartigen Anwendungen wurden über Popups auf legitimen Websites bereitgestellt.(Zitat: Volexity OceanLotus Nov 2017)

Les adversaires peuvent accéder à un système par le biais d'un utilisateur qui visite un site Web dans le cadre d'une navigation normale. Avec cette technique, le navigateur Web de l'utilisateur est généralement ciblé pour l'exploitation, mais les adversaires peuvent également utiliser des sites Web compromis pour des comportements de non-exploitation tels que l'acquisition de [Application Access Token] (/techniques/T1550/001).

Il existe de multiples façons de délivrer du code d'exploitation à un navigateur, notamment :

Un site Web légitime est compromis où les adversaires ont injecté une forme de code malveillant tel que JavaScript, iFrames et cross-site scripting.
Des publicités malveillantes sont payées et diffusées par des fournisseurs de publicité légitimes.
Les interfaces d'application Web intégrées sont exploitées pour l'insertion de tout autre type d'objet pouvant être utilisé pour afficher du contenu Web ou contenir un script qui s'exécute sur le client visiteur (par exemple, des messages de forum, des commentaires et d'autres contenus Web contrôlables par l'utilisateur).

Souvent, le site Web utilisé par un adversaire est un site visité par une communauté spécifique, comme le gouvernement, une industrie particulière ou une région, où l'objectif est de compromettre un utilisateur spécifique ou un ensemble d'utilisateurs sur la base d'un intérêt partagé. Ce type d'attaque ciblée est appelé une compromission web stratégique ou une attaque de type "watering hole". Il existe plusieurs exemples connus de ce type d'attaque.(Citation : Shadowserver Strategic Web Compromise)

Processus typique de compromission par drive-by :

Un utilisateur visite un site Web qui est utilisé pour héberger le contenu contrôlé par l'adversaire.
Les scripts s'exécutent automatiquement, recherchant généralement les versions du navigateur et des plugins pour une version potentiellement vulnérable.
- L'utilisateur peut être amené à assister à ce processus en activant les scripts ou les composants actifs du site Web et en ignorant les boîtes de dialogue d'avertissement.
Après avoir trouvé une version vulnérable, le code d'exploitation est livré au navigateur.
Si l'exploitation réussit, elle permet à l'adversaire d'exécuter du code sur le système de l'utilisateur, sauf si d'autres protections sont en place.
- Dans certains cas, une deuxième visite du site Web après l'analyse initiale est nécessaire avant que le code d'exploitation ne soit livré.

Contrairement à [Exploit Public-Facing Application] (/techniques/T1190), cette technique vise à exploiter le logiciel d'un client lors de la visite d'un site Web. Cela permet généralement à un adversaire d'accéder aux systèmes du réseau interne plutôt qu'aux systèmes externes qui peuvent se trouver dans une zone démilitarisée.

Les adversaires peuvent également utiliser des sites Web compromis pour amener un utilisateur à une application malveillante conçue pour [voler des jetons d'accès aux applications] (/techniques/T1528), comme les jetons OAuth, afin d'accéder à des applications et des informations protégées. Ces applications malveillantes ont été livrées par le biais de popups sur des sites Web légitimes.(Citation : Volexity OceanLotus Nov 2017)

Gli avversari possono ottenere l'accesso ad un sistema attraverso un utente che visita un sito web durante il normale corso della navigazione. Con questa tecnica, il browser web dell'utente è tipicamente mirato allo sfruttamento, ma gli avversari possono anche usare siti web compromessi per comportamenti non di sfruttamento come l'acquisizione di Application Access Token.

Esistono diversi modi di consegnare codice di exploit ad un browser, tra cui:

Un sito web legittimo viene compromesso dove gli avversari hanno iniettato qualche forma di codice malevolo come JavaScript, iFrames e cross-site scripting.
Gli annunci malevoli vengono pagati e serviti attraverso fornitori di annunci legittimi.
Le interfacce di applicazioni web incorporate vengono sfruttate per l'inserimento di qualsiasi altro tipo di oggetto che può essere usato per mostrare contenuto web o contenere uno script che viene eseguito sul client in visita (ad esempio post di forum, commenti e altri contenuti web controllabili dall'utente).

Spesso il sito web usato da un avversario è quello visitato da una comunità specifica, come il governo, un'industria particolare o una regione, dove l'obiettivo è compromettere un utente specifico o un insieme di utenti sulla base di un interesse condiviso. Questo tipo di attacco mirato viene definito un compromesso web strategico o attacco watering hole. Ci sono diversi esempi noti di questo fenomeno.(Citazione: Shadowserver Strategic Web Compromise)

Tipico processo di compromissione drive-by:

Un utente visita un sito web che ospita il contenuto controllato dall'avversario.
Gli script vengono eseguiti automaticamente, tipicamente cercando versioni del browser e plugin per una versione potenzialmente vulnerabile.
- All'utente può essere richiesto di assistere a questo processo abilitando lo scripting o i componenti attivi del sito web e ignorando le finestre di dialogo di avvertimento.
Una volta trovata una versione vulnerabile, il codice di exploit viene consegnato al browser.
Se lo sfruttamento ha successo, allora darà all'avversario l'esecuzione di codice sul sistema dell'utente, a meno che non ci siano altre protezioni.
- In alcuni casi è necessaria una seconda visita al sito dopo la scansione iniziale prima che venga consegnato il codice di exploit.

A differenza di Exploit Public-Facing Application, l'obiettivo di questa tecnica è sfruttare il software su un endpoint client dopo aver visitato un sito web. Questo darà comunemente ad un avversario l'accesso a sistemi sulla rete interna invece che a sistemi esterni che possono trovarsi in una DMZ.

Gli avversari possono anche usare siti web compromessi per consegnare un utente ad un'applicazione malevola progettata per Steal Application Access Token, come i token OAuth, per ottenere accesso ad applicazioni e informazioni protette. Queste applicazioni malevole sono state consegnate attraverso popup su siti web legittimi.(Citazione: Volexity OceanLotus Nov 2017)

Law Assessment

There exists an assessment but it was not translated or not approved for release. Please contact us about this assessment and provide a link to this assessment.

Article	Assessment
Art. 143 Abs. 1 StGB (Datenbeschaffung) Contribution Details Last update: 2021-11-8 Autoren: Roman Kost ⓘ	Il est envisageable que les attaques par drive-by download puissent être utilisées pour effacer des données sur un système cible, ce qui tomberait sous le coup de l'article 144bis du Code pénal. È concepibile che attacchi drive-by possano essere usati per cancellare dati su un sistema bersaglio, il che rientrerebbe nell'art. 144bis SCC. It is conceivable that drive-by attacks could be used to delete data on a target system, which would fall under Art. 144bis SCC. Es ist denkbar, dass Drive-By-Angriffe zum Löschen von Daten auf einem Zielsystem benutzt werden können, was unter Art. 144bis StGB fallen würde.
Art. 143^bis Abs. 1 StGB (Hacking) Contribution Details Last update: 2021-11-13 Autoren: Roman Kost, Viola Kost ⓘ	Très fondamentalement, les attaques par drive-by download exploitent les vulnérabilités d'un système qui se trouve dans la zone d'influence de l'auteur. Il s'agit classiquement de la visite d'un site web. Les attaques par drive-by download peuvent également se produire en ce qui concerne l'interface Bluetooth ou WLAN ou plus généralement dans le cas de tout type de communication numérique à laquelle participe un partenaire de communication avec un système vulnérable. En ce qui concerne la sécurité particulière exigée par le législateur, qu'il s'agit de contourner dans le cadre de l'infraction de piratage informatique visée à l'article 143bis, paragraphe 1 du Code pénal, les attaques par drive-by download nécessitent une grande discussion. Le simple état de fonctionnement d'un système est-il déjà considéré comme une "protection spéciale" ? Cela ne serait concevable que si l'on pouvait parler de "systèmes sûrs" au sens d'un système sans points faibles. Y a-t-il une différence entre un système qui ne présente aucune mesure de sécurité et un système dont l'utilisateur ne veut pas et ne doit pas supposer que quelqu'un d'autre accède à son système simplement parce qu'il navigue sur une page web préparée ? Ce scénario peut sembler extrême à première vue, mais il est trompeur : ce serait par exemple le cas d'un smartphone sans code PIN ou d'un ordinateur personnel sans mot de passe utilisateur. En principe, le système n'est pas accessible à des tiers. Il faut admettre que la protection de l'accès est de nature purement physique ou organisationnelle. Physique, par exemple, parce que l'auteur de l'infraction ne se trouve pas à proximité ; organisationnelle, par exemple, parce que l'auteur de l'infraction se trouve éventuellement à proximité (par exemple le voisin de table direct), mais que la simple présence de l'utilisateur de l'ordinateur l'empêche d'y accéder directement. Dans ce cas, il suffit que le comportement social habituel se traduise par le fait que l'on n'utilise pas simplement l'ordinateur d'autrui et encore moins lorsque quelqu'un est assis devant. La doctrine dominante présente souvent un exemple selon lequel il ne devrait pas y avoir de piratage en soi si l'auteur utilise directement le clavier d'un ordinateur pour se connecter illégalement au compte d'un tiers. Il a déjà été démontré que cela ne peut pas être vrai (mieux vaut mettre un lien vers la source : https://143bis.ch/kommentar/stgb-143bis/), donc ici juste brièvement : le piratage peut aussi se faire directement en utilisant un clavier, car la transmission par exemple via le câble USB n'est rien d'autre qu'une intrusion "par voie informatique". La communication se fait à travers toutes les couches OSI, c'est-à-dire du fil jusqu'au niveau du protocole (couche OSI 1), avec lequel un contrôleur USB ou le pilote de périphérique du système interprète les frappes qui lui sont envoyées. Un clavier n'est donc rien d'autre qu'un système de traitement de données. Contrairement au pirate qui se connecte à un compte à l'aide d'un clavier, dans le cas d'une attaque par drive-by download, l'attaquant profite du fait qu'il existe une vulnérabilité sur le système concerné. Cela soulève des questions. Si une personne accède à un ordinateur via un clavier et que cet ordinateur n'est pas protégé par un mot de passe, cette personne ne commet pas de piratage. Si elle utilise le clavier et saisit sans autorisation un mot de passe qui n'est pas le sien, elle est un pirate informatique au sens du droit pénal. La différence réside dans la protection particulière. Est-il possible maintenant que l'attaque par drive-by d'un ordinateur non sécurisé soit impunie ? Du point de vue de l'évaluation, il semble clair que cette attaque ne peut pas rester impunie. La paix informatique est troublée exactement de la même manière (et très souvent de manière massive). En revanche, si l'on se réfère au texte de l'article 143bis, paragraphe 1 du Code pénal et au principe central sine lege nulla poena, l'impunité doit être la réponse. Sur ce point, il y a clairement un besoin de rattrapage du côté législatif. Le fait qu'un système soit piraté lorsque des données de ce système étranger apparaissent à l'écran ne peut pas non plus être un critère valable. Cela n'a aucun fondement technique et se réfère uniquement à la perception d'un observateur non averti qui ne connaît pas les processus d'un système informatique. - Très fondamentalement, les attaques par drive-by download exploitent les vulnérabilités d'un système qui se trouve dans la zone d'influence de l'auteur. Il s'agit classiquement de la visite d'un site web. Les attaques par drive-by download peuvent également se produire en ce qui concerne l'interface Bluetooth ou WLAN ou plus généralement dans le cas de tout ... + Fondamentalmente, gli attacchi drive-by sfruttano le vulnerabilità di un sistema che si trova nella sfera d'influenza del perpetratore. Questo è classicamente una visita ad un sito web. Gli attacchi drive-by possono verificarsi anche in relazione all'interfaccia Bluetooth o WLAN o generalmente nel caso di qualsiasi tipo di comunicazione digitale in cui partecipa un partner di comunicazione con un sistema vulnerabile. Per quanto riguarda la sicurezza speciale richiesta dal legislatore per essere aggirata nel reato di hacking secondo l'articolo 143bis comma 1 SCC, c'è un grande bisogno di discussione nel caso di attacchi drive-by. Il semplice stato funzionale di un sistema è già considerato "specialmente protetto"? Questo sarebbe – se mai – concepibile solo se si potesse parlare di "sistemi sicuri" nel senso di un sistema senza vulnerabilità. C'è differenza se un sistema non ha alcuna precauzione di sicurezza, ma il suo utente non vuole e non deve presumere che qualcuno straniero acceda al suo sistema solo perché naviga su un sito preparato? Questo scenario può sembrare estremo a prima vista, ma è ingannevole: il suddetto sarebbe il caso, per esempio, di uno smartphone che non ha un PIN impostato o di un computer domestico privato senza una password utente. Il sistema non è fondamentalmente accessibile a terzi. Certo, la protezione dell'accesso è puramente fisica o organizzativa. Fisicamente, per esempio, perché il colpevole non è nelle vicinanze; organizzativamente, per esempio, perché il colpevole può essere nelle vicinanze (per esempio il vicino immediato al tavolo), ma gli viene impedito l'accesso diretto dalla semplice presenza dell'utente del computer. In questo caso è già sufficiente che il comportamento socialmente abituale abbia l'effetto che non si usa semplicemente il computer di altre persone e certamente non quando qualcuno vi è seduto davanti. Nella dottrina prevalente si fa spesso un esempio secondo il quale non c'è hacking di per sé se l'autore usa direttamente la tastiera di un computer per accedere illegalmente all'account di un'altra persona. Che questo non può essere corretto è già stato dimostrato (fonte link ancora migliore: https://143bis.ch/kommentar/stgb-143bis/), quindi qui solo brevemente: l'hacking può essere fatto anche direttamente usando una tastiera, poiché la trasmissione, ad esempio tramite il cavo USB, non è altro che un'intrusione "tramite un sistema di elaborazione dati". La comunicazione avviene attraverso tutti i livelli OSI, cioè dal filo al livello di protocollo (OSI layer 1), con il quale un controller USB o il driver del dispositivo del sistema interpretano le battute inviate. Una tastiera non è quindi altro che un sistema di elaborazione dati. A differenza dell'hacker che usa una tastiera per accedere ad un account, l'attaccante in un attacco drive-by sfrutta il fatto che esiste una vulnerabilità sul sistema in questione. Questo solleva delle domande. Se qualcuno accede ad un computer tramite una tastiera e questo computer non è protetto da una password, questa persona non sta commettendo hacking. Se usano la tastiera e inseriscono la password di qualcun altro senza autorizzazione, si tratta di hacking nel senso del diritto penale. La differenza sta nella sicurezza speciale. Può essere ora che l'attacco drive-by di un computer non protetto sia impunibile? In termini di valore, sembra chiaro che questo attacco non dovrebbe rimanere impunito. La pace del computer è disturbata esattamente allo stesso modo (e molto spesso nel modo più massiccio). Per quanto riguarda la formulazione dell'art. 143bis comma 1 SCC e il principio centrale sine lege nulla poena, tuttavia, l'impunità deve essere la risposta. Qui c'è chiaramente un bisogno di recuperare sul lato legislativo. Un criterio adeguato non può essere il fatto che un sistema sia stato violato se sullo schermo appaiono dati di questo sistema estraneo. Questo manca di una base tecnica e si riferisce esclusivamente alla percezione di un osservatore laico che non ha familiarità con i processi in un sistema informatico. - Fondamentalmente, gli attacchi drive-by sfruttano le vulnerabilità di un sistema che si trova nella sfera d'influenza del perpetratore. Questo è classicamente una visita ad un sito web. Gli attacchi drive-by possono verificarsi anche in relazione all'interfaccia Bluetooth o WLAN o generalmente nel caso di qualsiasi tipo di comunicazione digitale in cui partecipa un partner di ... + Very fundamentally, drive-by attacks exploit vulnerabilities in a system that enters the perpetrator's sphere of influence. This is classically a visit to a website. Drive-by attacks can also occur in relation to the Bluetooth or WLAN interface or quite generally in the case of any type of digital communication in which a communication partner with a vulnerable system participates. With regard to the special security required by the legislator to be circumvented in the offense of hacking under Art. 143bis para. 1 SCC, there is a great need for discussion in the case of drive-by attacks. Is the simple functional state of a system already considered "specially protected"? That would be – if at all – only conceivable if one could speak of "secure systems" in the sense of a system without vulnerabilities at all. Is there a difference if a system has no security precautions at all, but its user does not want and does not have to assume that someone foreign accesses his system just because he surfs on a prepared website? This scenario may seem extreme at first glance, but that is deceptive: the aforementioned would be the case, for example, with a smartphone that does not have a PIN set or a private home computer without a user password. The system is basically not accessible to third parties. Admittedly, access protection is purely physical or organizational in nature. Physically, for example, because the perpetrator is not in the vicinity; organizationally, for example, because the perpetrator may be in the vicinity (e.g., the immediate table neighbor), but he is prevented from direct access by the mere presence of the computer user. Here, it is already sufficient that socially customary behavior has an effect in such a way that one does not simply use other people's computers and certainly not when someone is sitting in front of it. In the prevailing doctrine, an example is often presented according to which per se hacking should not be present if the perpetrator directly uses the keyboard of a computer to illegally log into another's account. That this cannot be correct has already been shown (source even better link: https://143bis.ch/kommentar/stgb-143bis/), so here only briefly: Hacking can also be done directly by using a keyboard, since the transmission e.g. via the USB cable represents nothing other than an intrusion "by way of a data processing system". The communication takes place over all OSI layers, thus from the wire up to the protocol layer (OSI layer 1), with which a USB controller resp. the device driver of the system interprets the keystrokes sent to it. So with a Tatstatur there is nothing else than a data processing system. Unlike the hacker who uses a keyboard to log into an account, the attacker in a drive-by attack exploits the fact that a vulnerability exists on the system in question. This raises questions. If someone accesses a computer via a keyboard and that computer is not protected by a password, that person is not committing hacking. If she uses the keyboard and enters someone else's password without authorization, she is hacking in the sense of criminal law. The difference lies in the special security. Can it now be that the drive-by attack of a computer that is not secured is unpunishable? In terms of value, it seems clear that this attack should not go unpunished. Computer peace is disturbed in exactly the same way (and very often in the most massive way). With respect to the wording of Art. 143bis para. 1 StGB and the central principle sine lege nulla poena, however, impunity must be the answer. Here, clearly there is a need for catching up on the legislative side. No suitable criterion can then be the circumstance that a system is hacked, if data of this foreign system appear on the screen. This lacks a technical basis and relates solely to the perception of a lay observer who is not familiar with the processes in a computer system. - Very fundamentally, drive-by attacks exploit vulnerabilities in a system that enters the perpetrator's sphere of influence. This is classically a visit to a website. Drive-by attacks can also occur in relation to the Bluetooth or WLAN interface or quite generally in the case of any type of digital communication in which a communication partner with ... + Ganz grundsätzlich nutzen Drive-By-Angriffe Schwachstellen eines Systems aus, das sich in den Einflussbereich des Täters begibt. Das ist klassischerweise der Besuch einer Webseite. Drive-By-Angriffe können auch in Bezug auf die Bluetooth- oder WLAN-Schnittstelle erfolgen resp. ganz generell im Falle jeglicher Art von digitaler Kommunikation, bei der ein Kommunikationspartner mit einem verletzbaren System teilnimmt. In Bezug auf die vom Gesetzgeber geforderte besondere Sicherung, die es im Tatbestand des Hackings nach Art. 143bis Abs. 1 StGB zu umgehen gilt, besteht bei Drive-By-Angriffen grosser Diskussionsbedarf. Gilt der schlichte funktionsfähige Zustand eines Systems bereits als "besonders geschützt"? Das wäre – wenn überhaupt – nur dann denkbar, wenn man von "sicheren Systemen" im Sinne eines Systems ohne Schwachstellen überhaupt sprechen könnte. Gibt es einen Unterschied, wenn ein System keinerlei Sicherheitsvorkehrungen aufweist, dessen Benutzer aber nicht will und auch nicht davon ausgehen muss, dass jemand Fremdes auf sein System zugreift, nur weil er auf einer präparierten Webseite surft? Dieses Szenario mag auf den ersten Blick extrem sein, was aber täuscht: Das Genannte wäre zum Beispiel bei einem Smartphone der Fall, bei dem kein PIN eingestellt ist oder einem privaten Heimcomputer ohne Benutzerpasswort. Das System ist grundsätzlich nicht für Dritte zugreifbar. Zugegebenermassen ist der Zugriffschutz rein physikalischer oder organisatorischer Natur. Physikalisch z.B. deshalb, weil der Täter sich nicht in der Nähe befindet; organisatorisch bspw., weil der Täter sich zwar eventuell doch in der Nähe befindet (z.B. der direkte Tischnachbar), er aber durch die blosse Anwesenheit des Computerbenutzers am direkten Zugriff gehindert wird. Hier genügt bereits, dass sich sozialübliches Verhalten so auswirkt, dass man nicht einfach fremde Computer benutzt und schon gar nicht, wenn jemand davorsitzt. In der herrschenden Lehre wird häufig ein Beispiel vorgetragen, nach dem per se keine Hacking vorliegen solle, wenn der Täter direkt die Tastatur eines Computers benutzt, um sich unrechtmässig in einen fremden Account einzuloggen. Dass das nicht richtig sein kann, wurde bereits gezeigt (Quelle noch besser verlinken: https://143bis.ch/kommentar/stgb-143bis/), hier deshalb nur kurz: Gehackt werden kann auch direkt, indem man eine Tastatur benutzt, da die Übertragung z.B. über das USB-Kabel nichts anderes als ein Eindringen "auf dem Wege einer Datenverarbeitungsanlage" darstellt. Die Kommunikation erfolgt über sämtliche OSI-Layer, also vom Draht bis hin zur Protokollebene (OSI-Layer 1), mit der ein USB-Controller resp. der Gerätetreiber des Systems die an ihn geschickten Tastenschläge interpretiert. Bei einer Tatstatur liegt also nichts anderes als eine Datenverarbeitungsanlage vor. Im Unterschied zum Hacker, der sich mit Hilfe einer Tastatur in einen Account einloggt, nutzt der Angreifer bei einer Drive-By-Attacke die Tatsache aus, dass auf dem betreffenden System eine Schwachstelle existiert. Das wirft fragen auf. Greift jemand auf einen Computer über eine Tastatur zu und ist dieser Computer nicht durch ein Passwort geschützt, begeht diese Person kein Hacking. Benutzt sie die Tastatur und gibt unberechtigt ein fremdes Passwort ein, ist sie Hacker im Sinne des Strafrechts. Der Unterscheid liegt in der besonderen Sicherung. Kann es nun sein, dass die Drive-By-Attacke eines nicht gesicherten Computers straflos ist? Wertungsmässig scheint es klar zu sein, dass dieser Angriff nicht ungestraft sein darf. Der Computerfrieden wird in genau gleicher (und sehr häufig in massivster) Weise gestört. In Bezug auf den Wortlaut von Art. 143bis Abs. 1 StGB und den zentralen Grundsatz sine lege nulla poena hingegen, muss Straflosigkeit die Antwort sein. Hier ist klar Nachholbedarf von legislativer Seite gegeben. Kein taugliches Kriterium kann sodann der Umstand sein, dass ein System gehackt ist, wenn Daten dieses fremden Systems auf dem Bildschirm auftauchen. Das entbehrt einer technischen Grundlage und bezieht sich einzig auf die Wahrnehmung eines laienhaften Betrachters, dem die Abläufe in einem Computersystem nicht bekannt sind. - Ganz grundsätzlich nutzen Drive-By-Angriffe Schwachstellen eines Systems aus, das sich in den Einflussbereich des Täters begibt. Das ist klassischerweise der Besuch einer Webseite. Drive-By-Angriffe können auch in Bezug auf die Bluetooth- oder WLAN-Schnittstelle erfolgen resp. ganz generell im Falle jeglicher Art von digitaler Kommunikation, bei der ein Kommunikationspartner mit einem verletzbaren System teilnimmt. In Bezug ... +
Art. 144^bis Ziff. 1 StGB (Datenbeschädigung) Contribution Details Last update: 2021-11-13 Autoren: Roman Kost ⓘ	Il est concevable que les attaques par drive-by download puissent être utilisées pour effacer des données sur un système cible, ce qui tomberait sous le coup de l'art. 144bis CP. È concepibile che attacchi drive-by possano essere usati per cancellare dati su un sistema bersaglio, il che rientrerebbe nell'Art. 144bis SCC. It is conceivable that drive-by attacks could be used to delete data on a target system, which would fall under Article 144bis SCC. Es ist denkbar, dass Drive-By-Angriffe zum Löschen von Daten auf einem Zielsystem benutzt werden können, was unter Art. 144bis StGB fallen würde.

Forensics

Forensic Domain	Assessment
Log Files	Da sich ein Exploit im Rahmen einer Drive-By-Attacke in einer ersten Phase auf die angegriffene Applikation auswirkt, ist zuerst in allfälligen Konsolenoutputs oder applikationsinternen Logfiles nach Hinweisen zu suchen. Moderne Browser wie Firefox oder Chrome haben entsprechende Möglichkeiten. Es ist hingegen durchaus möglich, dass der Exploit keinerlei Output in diesen Logs oder einer Konsole bewirkt und die Logfacilities der Applikation darum wenig hilfreich sein könnten. Windows 10 bietet in der Pro-Version erweiterte Einstellungsmöglichkeiten, die das Loggen von Starts/Beendigungen erlauben; leider nicht per default aktiviert. Hier könnten sich laterale Bewegungen des Angreifers resp. dessen Software nachvollziehen lassen, in dem der Exploit weitere Prozesse auf dem angegriffenen System startet. Vorausgesetzt ist, dass der Exploit das Verlassen der Browserumgebung (und dessen allfällige Sandbox etc.) ermöglicht. Unter vielen Linuxdistributionen werden standardmässig zumindest Starts von Systemdienstens mitgeloggt. Für weitergehende Loggingfunktionaltität stehen Audit-Softwarepakete bereit, welche mit entsprechender Konfiguration unter vielem mehr auch das Kreieren und Beenden von Prozessen aufzeichnen (z.B. auditd unter diversen Linux-Distributionen). Sofern eine Schnittstelle zum Drive-By-Angriff benutzt wird, bspw. Bluetooth, WLAN etc., muss geprüft werden, ob die betreffenden Geräte Logeinträge aufweisen wie beispielsweise Einträge zum Verbindungsaufbau. Dieser Verbindungsaufbau ist Voraussetzung für eine erfolgreiche Drive-By-Injection. Ein versierter Angreifer hat in aller Regel seine Hardwareadressen wie beispielsweise die MAC-Adresse des WLAN-Adapters oder die BD_ADDR bei einem Bluetoothdevice abgeändert (gespooft). Diese Änderungen sind möglich, weil Hardwareadressen zwar in der Firmware oder einem ROM von Geräten hinterlegt werden, diese Adressen aber vereinfacht dargestellt zur Laufzeit Arbeitsspeicher vorliegen und dadurch vom System überschrieben werden können. In nicht wenigen Fällen passieren hier den Angreifern aus Unachtsamkeit Fehler (OPSEC-Fail) und sie benutzen echte Hardwareadressen. Wird ein Gerät eines mutmasslichen Angreifers sichergestellt, lässt sich in solchen Fällen eine sehr starke Indizienkette aufstellen, da Hardwareadressen pro Netzwerkschnittstelle weltweit einmalig vergeben werden. - Da sich ein Exploit im Rahmen einer Drive-By-Attacke in einer ersten Phase auf die angegriffene Applikation auswirkt, ist zuerst in allfälligen Konsolenoutputs oder applikationsinternen Logfiles nach Hinweisen zu suchen. Moderne Browser wie Firefox oder Chrome haben entsprechende Möglichkeiten. Es ist hingegen durchaus möglich, dass der Exploit keinerlei Output in diesen Logs oder einer Konsole bewirkt und die Logfacilities der Applikation ... + Comme un exploit dans le cadre d'une attaque par drive-by download se répercute dans un premier temps sur l'application attaquée, il faut d'abord rechercher des indices dans les éventuelles sorties de console ou les fichiers journaux internes de l'application. Les navigateurs modernes comme Firefox ou Chrome disposent de possibilités correspondantes. En revanche, il est tout à fait possible que l'exploit ne provoque aucune sortie dans ces logs ou dans une console et que les facilités de log de l'application ne soient donc pas d'une grande aide. Windows 10 offre des options de configuration avancées dans la version Pro qui permettent la journalisation des démarrages/arrêts ; malheureusement, elles ne sont pas activées par défaut. Cela pourrait permettre de suivre les mouvements latéraux de l'attaquant ou de son logiciel, dans la mesure où l'exploit lance d'autres processus sur le système attaqué. Cela suppose que l'exploit permette de quitter l'environnement du navigateur (et son éventuelle sandbox, etc.). Sous de nombreuses distributions Linux, les démarrages des services système sont au moins enregistrés par défaut. Pour des fonctionnalités de journalisation plus avancées, il existe des logiciels d'audit qui, avec une configuration appropriée, enregistrent entre autres la création et l'arrêt de processus (par exemple auditd sous diverses distributions Linux). Si une interface est utilisée pour une attaque par drive-by download, par exemple Bluetooth, WLAN, etc., il faut vérifier si les appareils concernés ont des entrées dans le journal, par exemple des entrées pour l'établissement de la connexion. L'établissement de la connexion est une condition préalable à la réussite d'une injection par drive-by download. Un attaquant expérimenté a généralement modifié (spoulé) ses adresses matérielles, comme l'adresse MAC de l'adaptateur WLAN ou le BD_ADDR d'un périphérique Bluetooth. Ces modifications sont possibles car les adresses matérielles sont certes stockées dans le firmware ou dans une ROM des appareils, mais ces adresses sont, pour simplifier, présentes dans la mémoire vive au moment de l'exécution et peuvent donc être écrasées par le système. Dans de nombreux cas, les attaquants commettent des erreurs d'inattention (OPSEC-Fail) et utilisent de vraies adresses matérielles. Si un appareil d'un attaquant présumé est saisi, il est possible dans de tels cas d'établir une très forte chaîne d'indices, car les adresses matérielles sont attribuées une seule fois par interface réseau dans le monde entier. - Comme un exploit dans le cadre d'une attaque par drive-by download se répercute dans un premier temps sur l'application attaquée, il faut d'abord rechercher des indices dans les éventuelles sorties de console ou les fichiers journaux internes de l'application. Les navigateurs modernes comme Firefox ou Chrome disposent de possibilités correspondantes. En revanche, il est tout ... + Poiché un exploit nel contesto di un attacco drive-by colpisce l'applicazione attaccata nella prima fase, la prima cosa da fare è cercare indizi in qualsiasi output della console o file di log interno all'applicazione. I browser moderni come Firefox o Chrome hanno opzioni corrispondenti. Tuttavia, è abbastanza possibile che l'exploit non causi nessun output in questi log o in una console e le strutture di log dell'applicazione potrebbero quindi essere di scarso aiuto. Windows 10 offre impostazioni estese nella versione Pro che permettono di registrare gli avvii/le uscite; purtroppo non è attivato di default. Qui si potrebbero tracciare i movimenti laterali dell'attaccante o del suo software, in cui l'exploit avvia ulteriori processi sul sistema attaccato. Questo presuppone che l'exploit permetta all'utente di lasciare l'ambiente del browser (e la sua sandbox, ecc.). In molte distribuzioni Linux, almeno l'avvio dei servizi di sistema viene registrato di default. Per funzionalità di log più estese, sono disponibili pacchetti software di audit che, con configurazione appropriata, registrano anche la creazione e la terminazione di processi, tra le altre cose (ad esempio auditd sotto varie distribuzioni Linux). Se un'interfaccia viene usata per un attacco drive-by, ad esempio Bluetooth, WLAN, ecc. si deve controllare se i dispositivi in questione hanno voci di registro, come quelle per stabilire una connessione. Questo stabilimento di connessione è un prerequisito per un'iniezione drive-by di successo. Un attaccante esperto di solito ha cambiato (spooft) gli indirizzi hardware, come l'indirizzo MAC dell'adattatore WLAN o il BD_ADDR di un dispositivo Bluetooth. Questi cambiamenti sono possibili perché gli indirizzi hardware sono memorizzati nel firmware o in una ROM dei dispositivi, ma in termini semplificati, questi indirizzi sono disponibili nella memoria runtime e possono quindi essere sovrascritti dal sistema. In parecchi casi gli aggressori sbagliano qui per disattenzione (OPSEC fail) e usano indirizzi hardware reali. Se viene sequestrato un dispositivo di un sospetto aggressore, in questi casi si può stabilire una catena di prove molto forte, dato che gli indirizzi hardware vengono assegnati una volta al mondo per interfaccia di rete. - Poiché un exploit nel contesto di un attacco drive-by colpisce l'applicazione attaccata nella prima fase, la prima cosa da fare è cercare indizi in qualsiasi output della console o file di log interno all'applicazione. I browser moderni come Firefox o Chrome hanno opzioni corrispondenti. Tuttavia, è abbastanza possibile che l'exploit non causi nessun output in ... + Since an exploit in the context of a drive-by attack affects the attacked application in an initial phase, the first thing to do is to look for clues in any console outputs or application-internal log files. Modern browsers such as Firefox or Chrome have corresponding options. However, it is quite possible that the exploit does not cause any output in these logs or a console and the log facilities of the application could therefore be of little help. Windows 10 offers advanced settings options in the Pro version that allow logging of starts/quits; unfortunately not enabled by default. Here, lateral movements of the attacker or its software could be tracked, in which the exploit starts further processes on the attacked system. This assumes that the exploit allows leaving the browser environment (and its possible sandbox, etc.). Under many Linux distributions, at least starts of system services are logged by default. For more extensive logging functionality, audit software packages are available which, with appropriate configuration, also record the creation and termination of processes, among many other things (e.g. auditd under various Linux distributions). If an interface is used for the drive-by attack, e.g. Bluetooth, WLAN etc., it must be checked whether the devices concerned have log entries such as entries for establishing a connection. This connection establishment is a prerequisite for successful drive-by injection. An experienced attacker will usually have modified (spooft) the hardware addresses, such as the MAC address of the WLAN adapter or the BD_ADDR of a Bluetooth device. These changes are possible because hardware addresses are stored in the firmware or ROM of devices, but in simple terms these addresses are available in runtime RAM and can therefore be overwritten by the system. In quite a few cases, attackers make mistakes here due to carelessness (OPSEC fail) and use real hardware addresses. If a device belonging to a suspected attacker is seized, a very strong chain of evidence can be established in such cases, since hardware addresses are assigned once worldwide per network interface. - Since an exploit in the context of a drive-by attack affects the attacked application in an initial phase, the first thing to do is to look for clues in any console outputs or application-internal log files. Modern browsers such as Firefox or Chrome have corresponding options. However, it is quite possible that the exploit does ... +
Operating Systems	Falls der Angreifer nach einer Drive-By-Attacke Persitenz erreicht, wären bei den angewandten Techniken unterschiedliche Beweisquellen wie z.B. die Windows-Registry mit den verschiedenen Startup-Einträgen zu prüfen, ebenso wie modifizierte Bootsektoren, Veränderungen an Systemdateien, neue oder veränderte Browserplugins, neu erstellte Benutzeraccounts, neue Cron-Jobs, neue scheduled Tasks etc. pp. Siehe dazu detaillierter PERSISTENCE /tactics/TA0003 (NOCH AUTOMATISCHE VERLINKUNG ENTWICKELN)). - Falls der Angreifer nach einer Drive-By-Attacke Persitenz erreicht, wären bei den angewandten Techniken unterschiedliche Beweisquellen wie z.B. die Windows-Registry mit den verschiedenen Startup-Einträgen zu prüfen, ebenso wie modifizierte Bootsektoren, Veränderungen an Systemdateien, neue oder veränderte Browserplugins, neu erstellte Benutzeraccounts, neue Cron-Jobs, neue scheduled Tasks etc. pp. Siehe dazu detaillierter PERSISTENCE /tactics/TA0003 (NOCH AUTOMATISCHE VERLINKUNG ENTWICKELN)). + Si l'attaquant atteint la persistance après une attaque par drive-by download, les techniques utilisées impliqueraient l'examen de différentes sources de preuves, telles que le registre Windows avec les différentes entrées de démarrage, ainsi que les secteurs de démarrage modifiés, les changements dans les fichiers système, les plugins de navigateur nouveaux ou modifiés, les comptes d'utilisateur nouvellement créés, les nouvelles tâches Cron, les nouvelles tâches programmées, etc. pp. Voir plus en détail PERSISTENCE /tactics/TA0003 (DEVELOPPER UN LIEN AUTOMATIQUE)). - Si l'attaquant atteint la persistance après une attaque par drive-by download, les techniques utilisées impliqueraient l'examen de différentes sources de preuves, telles que le registre Windows avec les différentes entrées de démarrage, ainsi que les secteurs de démarrage modifiés, les changements dans les fichiers système, les plugins de navigateur nouveaux ou modifiés, les comptes d'utilisateur ... + Se l'aggressore raggiunge la persistenza dopo un attacco drive-by, le tecniche usate comporterebbero il controllo di diverse fonti di prova come il registro di Windows con le varie voci di avvio, nonché settori di avvio modificati, modifiche ai file di sistema, plugin del browser nuovi o modificati, account utente appena creati, nuovi cron job, nuovi compiti programmati, ecc. Veda più in dettaglio PERSISTENZA /tattica/TA0003 (NON SVILUPPARE MAI IL COLLEGAMENTO AUTOMATICO)). If the attacker achieves persistence after a drive-by attack, the techniques used would involve checking different sources of evidence such as the Windows registry with the various startup entries, as well as modified boot sectors, changes to system files, new or modified browser plugins, newly created user accounts, new cron jobs, new scheduled tasks, etc. pp. See more detailed PERSISTENCE /tactics/TA0003 (NEVER DEVELOP AUTOMATIC LINKING)).
NIDS/Network	Um Drive-By-Angriffe zu detektieren, muss ein NIDS den Traffic lesen können. Nimmt man bspw. eine Drive-By-Attacke auf einen Browser, so wird die Kommunikation mit diesem Browser heute mit grösster Wahrscheinlichkeit verschlüsselt erfolgen (TLS/SSL). In solchen Fällen müsste das NIDS auf einem transparenten Proxy-Server laufen, der die Verschlüsselung aufbricht und die Kommunikation analysiert. Dazu kommt, dass das NIDS im Besitz der notwendigen Signaturen des Angriffs sein muss. Wendet der Angreifer eine 0-Day-Attacke, so fehlt es an der notwendigen Signatur und das NIDS bemerkt den Angriff nicht. Dementsprechend finden sich in den Logfiles keine Hinweise. Hält das NIDS ganz grundsätzlich für eine gewisse Zeit generell allen Datenverkehr vor, so ist es denkbar, dass man nachträglich, nach dem der konkrete Angriff, dessen Signatur, seine Payload oder die wesentlichen Teile davon bekannt sind, den effektiven Angriff nachvollziehen und einem Täter zuweisen kann. Diese Vorratsdatenspeicherung wirft datenschutzrechtliche Fragen auf und ist bei grossen Datenvolumen mit grossem Aufwand verbunden. Bei grossen Datenvolumen wird es regelmässig notwendig sein, gewisse Protokolle oder Dateninhalte auszuschliessen (bspw. Videoübertragung, Audio- und Video-Streams, VoIP-Traffic etc.). Das hat wiederum zur Konsequenz, dass man auf diesem Auge dann blind ist und Angriffe über die ignorierten Protokolle und Dateninhalte nicht erkannt werden. - Um Drive-By-Angriffe zu detektieren, muss ein NIDS den Traffic lesen können. Nimmt man bspw. eine Drive-By-Attacke auf einen Browser, so wird die Kommunikation mit diesem Browser heute mit grösster Wahrscheinlichkeit verschlüsselt erfolgen (TLS/SSL). In solchen Fällen müsste das NIDS auf einem transparenten Proxy-Server laufen, der die Verschlüsselung aufbricht und die Kommunikation analysiert. Dazu kommt, dass das NIDS im Besitz ... + Pour détecter les attaques par drive-by download, un NIDS doit pouvoir lire le trafic. Si l'on prend par exemple une attaque par drive-by download sur un navigateur, la communication avec ce navigateur est aujourd'hui très probablement cryptée (TLS/SSL). Dans ce cas, le NIDS devrait fonctionner sur un serveur proxy transparent qui casse le cryptage et analyse la communication. A cela s'ajoute le fait que le NIDS doit être en possession des signatures nécessaires de l'attaque. Si l'attaquant utilise une attaque 0-day, il n'a pas la signature nécessaire et le NIDS ne remarque pas l'attaque. Par conséquent, aucune indication ne figure dans les fichiers journaux. Si le NIDS conserve en principe tout le trafic pendant un certain temps, il est concevable qu'après avoir pris connaissance de l'attaque concrète, de sa signature, de sa charge utile ou des parties essentielles de celle-ci, il soit possible de retracer l'attaque effective et de l'attribuer à un auteur. Cette conservation des données soulève des questions en matière de protection des données et, en cas de volumes de données importants, elle est liée à des efforts considérables. Pour les gros volumes de données, il sera régulièrement nécessaire d'exclure certains protocoles ou contenus de données (par ex. transmission vidéo, flux audio et vidéo, trafic VoIP, etc.) Cela a pour conséquence que l'on est alors aveugle et que les attaques via les protocoles et contenus de données ignorés ne sont pas détectées. - Pour détecter les attaques par drive-by download, un NIDS doit pouvoir lire le trafic. Si l'on prend par exemple une attaque par drive-by download sur un navigateur, la communication avec ce navigateur est aujourd'hui très probablement cryptée (TLS/SSL). Dans ce cas, le NIDS devrait fonctionner sur un serveur proxy transparent qui casse le cryptage ... + Per rilevare gli attacchi drive-by, un NIDS deve essere in grado di leggere il traffico. Per esempio, se fa un attacco drive-by a un browser, la comunicazione con questo browser sarà molto probabilmente criptata oggi (TLS/SSL). In questi casi, il NIDS dovrebbe funzionare su un server proxy trasparente che rompe la crittografia e analizza la comunicazione. Inoltre il NIDS deve essere in possesso delle firme necessarie dell'attacco. Se l'attaccante usa un attacco 0-day, manca la firma necessaria e il NIDS non nota l'attacco. Di conseguenza, non ci sono indicazioni nei file di registro. Se il NIDS generalmente conserva tutto il traffico di dati per un certo periodo di tempo, è concepibile che dopo aver conosciuto l'attacco specifico, la sua firma, il suo payload o le parti essenziali di esso, l'attacco effettivo possa essere rintracciato e assegnato ad un esecutore. Questa conservazione dei dati solleva questioni di legge sulla protezione dei dati ed è associata a grandi spese nel caso di grandi volumi di dati. Con grandi volumi di dati, sarà regolarmente necessario escludere certi protocolli o contenuti di dati (ad esempio trasmissione video, flussi audio e video, traffico VoIP, ecc.) Questo a sua volta ha la conseguenza che si è poi ciechi in questo occhio e gli attacchi attraverso i protocolli e il contenuto dei dati ignorati non vengono rilevati. - Per rilevare gli attacchi drive-by, un NIDS deve essere in grado di leggere il traffico. Per esempio, se fa un attacco drive-by a un browser, la comunicazione con questo browser sarà molto probabilmente criptata oggi (TLS/SSL). In questi casi, il NIDS dovrebbe funzionare su un server proxy trasparente che rompe la crittografia e analizza ... + To detect drive-by attacks, a NIDS must be able to read the traffic. For example, if you take a drive-by attack on a browser, the communication with that browser today will most likely be encrypted (TLS/SSL). In such cases, the NIDS would have to run on a transparent proxy server that breaks the encryption and analyzes the communication. In addition, the NIDS must be in possession of the necessary signatures of the attack. If the attacker uses a 0-day attack, the necessary signature is missing and the NIDS does not notice the attack. Accordingly, there are no indications in the log files. If the NIDS generally retains all data traffic for a certain period of time, it is conceivable that, after the specific attack, its signature, its payload or the essential parts of it are known, it will be possible to subsequently trace the effective attack and assign it to a perpetrator. This data retention raises questions of data protection law and is associated with great expense in the case of large data volumes. With large data volumes, it will regularly be necessary to exclude certain protocols or data content (e.g. video transmission, audio and video streams, VoIP traffic, etc.). This in turn has the consequence that one is then blind on this eye and attacks via the ignored protocols and data content are not detected. - To detect drive-by attacks, a NIDS must be able to read the traffic. For example, if you take a drive-by attack on a browser, the communication with that browser today will most likely be encrypted (TLS/SSL). In such cases, the NIDS would have to run on a transparent proxy server that breaks the encryption ... +
HIDS/Host	Vielversprechend sind bei diesem Angriff gut konfigurierte HIDS, mit denen der Start von Applikationen geloggt wird, die z.B. aus der angegriffenen Anwendung (hier sehr häufig ein Browser) ausbrechen und weitere Prozesse starten. Hier lassen sich auch allfällige Privilege Escalations nachvollziehen. There exists an assessment but it was not translated or not approved for release. Please contact us about this assessment and provide a link to this assessment. Les HIDS bien configurés sont très prometteurs pour cette attaque. Ils permettent de journaliser le lancement d'applications qui, par exemple, s'échappent de l'application attaquée (très souvent un navigateur dans ce cas) et lancent d'autres processus. Il est également possible d'y tracer d'éventuelles escalades de privilèges. HIDS ben configurati, che registrano l'avvio di applicazioni che, per esempio, escono dall'applicazione attaccata (in questo caso molto spesso un browser) e avviano ulteriori processi, sono promettenti per questo attacco. Anche qualsiasi escalation di privilegi può essere rintracciata qui. Well-configured HIDS, which log the start of applications that, for example, break out of the attacked application (in this case very often a browser) and start further processes, are promising for this attack. Any privilege escalations can also be traced here.
Applications	Sofern die angegriffene Applikation resp. der angegriffene Prozess über eine Logfacility verfügt und nach entfalteter Wirkung tatsächlich ein Output im Log generiert wird, bestehen Chancen, verwertbare Beweise oder weiterführende Indizien aus der Applikation selbst zu gewinnen. There exists an assessment but it was not translated or not approved for release. Please contact us about this assessment and provide a link to this assessment. Si l'application ou le processus attaqué dispose d'une capacité de journalisation et qu'une sortie est effectivement générée dans le journal après le déploiement de l'effet, il existe des chances d'obtenir des preuves exploitables ou des indices supplémentaires à partir de l'application elle-même. Se l'applicazione attaccata o il processo attaccato ha una funzione di log e viene effettivamente generato un output nel log dopo lo svolgimento dell'effetto, c'è la possibilità di ottenere prove utilizzabili o ulteriori indicazioni dall'applicazione stessa. If the attacked application or process has a log facility and an output is actually generated in the log after the attack has taken effect, there is a chance of obtaining usable evidence or further indications from the application itself.
Data Media	Je nach Auswirkung des eingesetzten Exploits bei einem Drive-By-Anrgiff sind Veränderungen an Datenträgern denkbar. Es können Daten geschrieben oder gelöscht werden. Solche Veränderungen können Hinweise auf das Vorgehen der Täterschaft und den eingesetzten Exploit geben. Datenträger sind insbesondere zum Erreichen von Persistence von Relevanz, es wird an dieser Stelle auf PERSISTENCE /tactics/TA0003) verwiesen. There exists an assessment but it was not translated or not approved for release. Please contact us about this assessment and provide a link to this assessment. En fonction de l'impact de l'exploit utilisé lors d'une attaque par drive-by download, des modifications peuvent être apportées aux supports de données. Des données peuvent être écrites ou effacées. De telles modifications peuvent donner des indications sur le mode opératoire de l'auteur et sur l'exploit utilisé. Les supports de données sont particulièrement importants pour atteindre la persistance, nous renvoyons ici à PERSISTENCE /tactics/TA0003). A seconda dell'effetto dell'exploit usato in un attacco drive-by, sono concepibili modifiche ai supporti dati. I dati possono essere scritti o cancellati. Tali cambiamenti possono fornire indizi sull'approccio dell'autore e sull'exploit utilizzato. I portatori di dati sono particolarmente rilevanti per raggiungere la persistenza; a questo punto si fa riferimento a PERSISTENZA /tattica/TA0003). Depending on the effect of the exploit used in a drive-by attack, changes to data media are conceivable. Data can be written or deleted. Such changes can provide clues about the actions of the perpetrator and the exploit used. Data carriers are particularly relevant for achieving persistence; reference is made at this point to PERSISTENCE /tactics/TA0003).
Mobile Devices	Smartphones wie sämtliche andere mit Browsern ausgestattete Geräte sind von Drive-By-Attacken besonders betroffen. Um Drive-By-Angriffe forensisch nachvollziehen zu können, sind die bereits erwähnten Forensikdomänen einzeln zu analysieren. Aus der Eigenschaft, dass die betroffenen Geräte mobil sind, ergeben sich keine speziellen forensischen Besonderheiten oder Erkenntnismöglichkeiten. There exists an assessment but it was not translated or not approved for release. Please contact us about this assessment and provide a link to this assessment. Les smartphones et tous les autres appareils équipés d'un navigateur sont particulièrement touchés par les attaques par drive-by download. Pour comprendre les attaques par drive-by download, il faut analyser individuellement les domaines d'expertise mentionnés précédemment. Le fait que les appareils concernés soient mobiles n'entraîne pas de particularités ou de possibilités de constatation spéciales pour la police scientifique. Gli smartphone, come tutti gli altri dispositivi dotati di browser, sono particolarmente colpiti dagli attacchi drive-by. Per poter rintracciare forensicamente gli attacchi drive-by, i domini forensi già menzionati devono essere analizzati individualmente. Il fatto che i dispositivi colpiti siano mobili non comporta nessuna caratteristica forense speciale o opportunità di conoscenza. Smartphones, like all other browser-equipped devices, are particularly affected by drive-by attacks. In order to be able to trace drive-by attacks forensically, the forensic domains already mentioned must be analyzed individually. The fact that the affected devices are mobile does not result in any special forensic features or opportunities for insight.

ID: T1189

Sub-techniques: No sub-techniques

ⓘ

Tactic: Initial Access

ⓘ

Platforms: Linux, SaaS, Windows, macOS

ⓘ

Permissions Required: User

Contributors: Jeff Sakowicz, Microsoft Identity Developer Platform Services (IDPM Services); Saisha Agrawal, Microsoft Threat Intelligent Center (MSTIC)

Version: 1.3

Created: 18 April 2018

Last Modified: 28 July 2021

Translations: DE FR IT EN

Schweizerisches Strafgesetzbuch (StGB)

Relevant Articles:

Art. 143 Abs. 1 StGB (Datenbeschaffung)

Art. 143^bis Abs. 1 StGB (Hacking)

Art. 144^bis Ziff. 1 StGB (Datenbeschädigung)

Relevant Forensic Domains:

Log Files Operating Systems NIDS/Network HIDS/Host Applications Data Media Mobile Devices

Provided by LAYER 8

Procedure Examples

ID	Name	Description
G0138	Andariel	Andariel has used watering hole attacks, often with zero-day exploits, to gain initial access to victims within a specific IP range.^[3]^[4]
G0073	APT19	APT19 performed a watering hole attack on forbes.com in 2014 to compromise targets.^[5]
G0050	APT32	APT32 has infected victims by tricking them into visiting compromised watering hole websites.^[6]^[7]
G0067	APT37	APT37 has used strategic web compromises, particularly of South Korean websites, to distribute malware. The group has also used torrent file-sharing sites to more indiscriminately disseminate malware to victims. As part of their compromises, the group has used a Javascript based profiler called RICECURRY to profile a victim's web browser and deliver malicious code accordingly.^[8]^[9]^[10]
G0082	APT38	APT38 has conducted watering holes schemes to gain initial access to victims.^[11]^[12]
S0606	Bad Rabbit	Bad Rabbit spread through watering holes on popular sites by injecting JavaScript into the HTML body or a `.js` file.^[13]^[14]
G0060	BRONZE BUTLER	BRONZE BUTLER compromised three Japanese websites using a Flash exploit to perform watering hole attacks.^[15]
S0482	Bundlore	Bundlore has been spread through malicious advertisements on websites.^[16]
G0070	Dark Caracal	Dark Caracal leveraged a watering hole to serve up malicious code.^[17]
G0012	Darkhotel	Darkhotel used embedded iframes on hotel login portals to redirect selected victims to download malware.^[18]
G0035	Dragonfly	Dragonfly has compromised targets via strategic web compromise (SWC) utilizing a custom exploit kit.^[19]
G0074	Dragonfly 2.0	Dragonfly 2.0 compromised legitimate organizations' websites to create watering holes to compromise victims.^[20]
G0066	Elderwood	Elderwood has delivered zero-day exploits and malware to victims by injecting malicious code into specific public Web pages visited by targets within a particular sector.^[21]^[22]^[23]
S0531	Grandoreiro	Grandoreiro has used compromised websites and Google Ads to bait victims into downloading its installer.^[24]^[25]
S0215	KARAE	KARAE was distributed through torrent file-sharing websites to South Korean victims, using a YouTube video downloader application as a lure.^[9]
G0032	Lazarus Group	Lazarus Group delivered RATANKBA to victims via a compromised legitimate website.^[26]
G0077	Leafminer	Leafminer has infected victims using watering holes.^[27]
G0065	Leviathan	Leviathan has infected victims using watering holes.^[28]
S0451	LoudMiner	LoudMiner is typically bundled with pirated copies of Virtual Studio Technology (VST) for Windows and macOS.^[29]
G0095	Machete	Machete has distributed Machete through a fake blog website.^[30]
G0040	Patchwork	Patchwork has used watering holes to deliver files with exploits to initial victims.^[31]^[32]
G0068	PLATINUM	PLATINUM has sometimes used drive-by attacks against vulnerable browser plugins.^[33]
S0216	POORAIM	POORAIM has been delivered through compromised sites acting as watering holes.^[9]
G0056	PROMETHIUM	PROMETHIUM has used watering hole attacks to deliver malicious versions of legitimate installers.^[34]
S0496	REvil	REvil has infected victim machines through compromised websites and exploit kits.^[35]^[36]^[37]^[38]
G0048	RTM	RTM has distributed its malware via the RIG and SUNDOWN exploit kits, as well as online advertising network `Yandex.Direct`.^[39]^[40]
G0027	Threat Group-3390	Threat Group-3390 has extensively used strategic web compromises to target victims.^[41]^[42]
G0134	Transparent Tribe	Transparent Tribe has used websites with malicious hyperlinks and iframes to infect targeted victims with Crimson, njRAT, and other malicious tools.^[43]^[44]^[45]
G0010	Turla	Turla has infected victims using watering holes.^[46]
G0124	Windigo	Windigo has distributed Windows malware via drive-by downloads.^[47]
G0112	Windshift	Windshift has used compromised websites to register custom URL schemes on a remote system.^[48]

Mitigations

ID	Mitigation	Description
M1048	Application Isolation and Sandboxing	Browser sandboxes can be used to mitigate some of the impact of exploitation, but sandbox escapes may still exist.^[49]^[50] Other types of virtualization and application microsegmentation may also mitigate the impact of client-side exploitation. The risks of additional exploits and weaknesses in implementation may still exist for these types of systems.^[50]
M1050	Exploit Protection	Security applications that look for behavior used during exploitation such as Windows Defender Exploit Guard (WDEG) and the Enhanced Mitigation Experience Toolkit (EMET) can be used to mitigate some exploitation behavior. ^[51] Control flow integrity checking is another way to potentially identify and stop a software exploit from occurring. ^[52] Many of these protections depend on the architecture and target application binary for compatibility.
M1021	Restrict Web-Based Content	For malicious code served up through ads, adblockers can help prevent that code from executing in the first place. Script blocking extensions can help prevent the execution of JavaScript that may commonly be used during the exploitation process.
M1051	Update Software	Ensure all browsers and plugins kept updated can help prevent the exploit phase of this technique. Use modern browsers with security features turned on.

Detection

ID	Data Source	Data Component
DS0015	Application Log	Application Log Content
DS0022	File	File Creation
DS0029	Network Traffic	Network Connection Creation
		Network Traffic Content
DS0009	Process	Process Creation

Firewalls and proxies can inspect URLs for potentially known-bad domains or parameters. They can also do reputation-based analytics on websites and their requested resources such as how old a domain is, who it's registered to, if it's on a known bad list, or how many other users have connected to it before.

Network intrusion detection systems, sometimes with SSL/TLS inspection, can be used to look for known malicious scripts (recon, heap spray, and browser identification scripts have been frequently reused), common script obfuscation, and exploit code.

Detecting compromise based on the drive-by exploit from a legitimate website may be difficult. Also look for behavior on the endpoint system that might indicate successful compromise, such as abnormal behavior of browser processes. This could include suspicious files written to disk, evidence of Process Injection for attempts to hide execution, evidence of Discovery, or other unusual network traffic that may indicate additional tools transferred to the system.

Firewalls und Proxies können URLs auf potenziell schädliche Domains oder Parameter untersuchen. Sie können auch reputationsbasierte Analysen von Websites und den von ihnen angeforderten Ressourcen durchführen, z. B. wie alt eine Domain ist, auf wen sie registriert ist, ob sie auf einer Liste bekannter böser Domains steht oder wie viele andere Benutzer sich bereits mit ihr verbunden haben.

Systeme zur Erkennung von Eindringlingen in Netzwerke, manchmal mit SSL/TLS-Inspektion, können verwendet werden, um nach bekannten bösartigen Skripten (Recon-, Heap-Spray- und Browser-Identifikationsskripte wurden häufig wiederverwendet), allgemeiner Skriptverschleierung und Exploit-Code zu suchen.

Die Erkennung einer Kompromittierung auf der Grundlage eines Drive-by-Exploits von einer legitimen Website aus kann schwierig sein. Achten Sie auch auf Verhaltensweisen auf dem Endpunktsystem, die auf eine erfolgreiche Kompromittierung hindeuten könnten, wie z.B. abnormales Verhalten von Browser-Prozessen. Dazu könnten verdächtige Dateien gehören, die auf die Festplatte geschrieben werden, Hinweise auf Process Injection für Versuche, die Ausführung zu verbergen, Hinweise auf Discovery oder anderen ungewöhnlichen Netzwerkverkehr, der auf zusätzliche Tools hinweisen könnte, die auf das System übertragen wurden.

Les pare-feu et les proxies peuvent inspecter les URL à la recherche de domaines ou de paramètres potentiellement mauvais connus. Ils peuvent également effectuer des analyses basées sur la réputation des sites Web et des ressources qu'ils demandent, comme l'ancienneté d'un domaine, l'identité de son propriétaire, s'il figure sur une liste de mauvais domaines connus ou combien d'autres utilisateurs s'y sont déjà connectés.

Les systèmes de détection d'intrusion dans le réseau, parfois avec inspection SSL/TLS, peuvent être utilisés pour rechercher des scripts malveillants connus (les scripts de reconnaissance, de vaporisation du tas et d'identification du navigateur ont été fréquemment réutilisés), l'obfuscation de scripts courants et le code d'exploitation.

La détection d'une compromission basée sur l'exploit drive-by à partir d'un site Web légitime peut être difficile. Recherchez également un comportement sur le système d'extrémité qui pourrait indiquer une compromission réussie, comme un comportement anormal des processus du navigateur. Il peut s'agir de fichiers suspects écrits sur le disque, de preuves de [Process Injection] (/techniques/T1055) pour des tentatives de dissimulation d'exécution, de preuves de découverte ou d'autres trafics réseau inhabituels qui peuvent indiquer des outils supplémentaires transférés sur le système.

I firewall e i proxy possono ispezionare gli URL alla ricerca di domini o parametri potenzialmente noti come cattivi. Possono anche fare analisi basate sulla reputazione dei siti web e delle risorse richieste, come ad esempio quanto è vecchio un dominio, a chi è registrato, se è in una lista di cattivi conosciuti o quanti altri utenti si sono collegati ad esso prima.

I sistemi di rilevamento delle intrusioni di rete, a volte con ispezione SSL/TLS, possono essere usati per cercare script maligni noti (gli script recon, heap spray e di identificazione del browser sono stati riutilizzati spesso), offuscamento di script comuni e codice exploit.

Rilevare una compromissione basata sull'exploit drive-by da un sito legittimo può essere difficile. Cerchi anche un comportamento sul sistema endpoint che possa indicare una compromissione riuscita, come un comportamento anormale dei processi del browser. Questo potrebbe includere file sospetti scritti su disco, prove di Process Injection per tentativi di nascondere l'esecuzione, prove di Discovery, o altro traffico di rete insolito che potrebbe indicare strumenti aggiuntivi trasferiti al sistema.