home.social

#operationtriangulation — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #operationtriangulation, aggregated by home.social.

  1. Im März 2026 haben Kaspersky-Sicherheitsexperten eine neue Bedrohung für iPhones entdeckt: das Coruna iOS Exploit Framework.

    Mehr dazu: digiprax.maniabel.work/archiv/

    #coruna #iOS #iPhone #OperationTriangulation

  2. @purism Kaspersky also agreed with this after their #iPhones were hacked:

    "The main reason for this incident is the proprietary nature of iOS... a “black box”, in which spyware like Triangulation can hide for years... a perfect haven for spyware... users are given the illusion of security associated with the complete opacity of the system.

    "What actually happens in iOS is unknown to cybersecurity experts, and the absence of news about attacks in no way indicates their being impossible – as we’ve just seen."

    kaspersky.com/blog/triangulati

    A few other researchers did not shy away from calling the undocumented issue that made this possible a #backdoor!

    #OperationTriangulation #Apple #iOS #security #OpenSource #OpenSourceSecurity #FreeSoftware

  3. #Hörtipp
    Der #Deutschlandfunk hat einen interessanten 6-teiligen Podcast über Spionagesoftware auf dem Handy veröffentlicht. Er beginnt mit einer spannenden Recherche über #OperationTriangulation, setzt sich dann aber grundsätzlich mit geheimdienstlicher Cyberspionage auseinander.
    "Es geht darum, wer über wen Macht hat und ob wir davon überhaupt etwas mitbekommen. (...) Wir brauchen nicht nur Updates, die unsere Geräte sicherer machen oder bessere Passwörter, wir brauchen Transparenz und eine demokratische Debatte, die nicht nur militärisch oder technisch geführt werden sollte."
    #darkagent #podcast
    deutschlandfunk.de/dark-avenge

  4. Wieder mal eine #Hörempfehlung im Bereich #Podcast: Die Podcast-Reihe #DarkAgent präsentiert die lange Recherche mehrere Journalist:innen zu #OperationTriangulation, einen der umfassendsten und mysteriösesten Angriffe auf Smartphones bzw. iPhones – auch bekannt aus diesem Vortrag beim #37c3: media.ccc.de/v/37c3-11859-oper
    Merkwürdigerweise will #Kaspersky nicht mehr so gern, dass ihre Mitarbeiter:innen über das Thema sprechen. 👀 Was genau hinter dem Angriff steckt, ist unklar.

    Bisher zwei Folgen verfügbar, erst ab Montag auch frei per #RSS. jeden Montag eine neue Folge.
    deutschlandfunk.de/dark-avenge

    #Überwachung #Privacy #Radio #Deutschlandfunk

  5. Wieder mal eine #Hörempfehlung im Bereich #Podcast: Die Podcast-Reihe #DarkAgent präsentiert die lange Recherche mehrere Journalist:innen zu #OperationTriangulation, einen der umfassendsten und mysteriösesten Angriffe auf Smartphones bzw. iPhones – auch bekannt aus diesem Vortrag beim #37c3: media.ccc.de/v/37c3-11859-oper
    Merkwürdigerweise will #Kaspersky nicht mehr so gern, dass ihre Mitarbeiter:innen über das Thema sprechen. 👀 Was genau hinter dem Angriff steckt, ist unklar.

    Bisher zwei Folgen verfügbar, erst ab Montag auch frei per #RSS. jeden Montag eine neue Folge.
    deutschlandfunk.de/dark-avenge

    #Überwachung #Privacy #Radio #Deutschlandfunk

  6. Wieder mal eine #Hörempfehlung im Bereich #Podcast: Die Podcast-Reihe #DarkAgent präsentiert die lange Recherche mehrere Journalist:innen zu #OperationTriangulation, einen der umfassendsten und mysteriösesten Angriffe auf Smartphones bzw. iPhones – auch bekannt aus diesem Vortrag beim #37c3: media.ccc.de/v/37c3-11859-oper
    Merkwürdigerweise will #Kaspersky nicht mehr so gern, dass ihre Mitarbeiter:innen über das Thema sprechen. 👀 Was genau hinter dem Angriff steckt, ist unklar.

    Bisher zwei Folgen verfügbar, erst ab Montag auch frei per #RSS. jeden Montag eine neue Folge.
    deutschlandfunk.de/dark-avenge

    #Überwachung #Privacy #Radio #Deutschlandfunk

  7. Wieder mal eine #Hörempfehlung im Bereich #Podcast: Die Podcast-Reihe #DarkAgent präsentiert die lange Recherche mehrere Journalist:innen zu #OperationTriangulation, einen der umfassendsten und mysteriösesten Angriffe auf Smartphones bzw. iPhones – auch bekannt aus diesem Vortrag beim #37c3: media.ccc.de/v/37c3-11859-oper
    Merkwürdigerweise will #Kaspersky nicht mehr so gern, dass ihre Mitarbeiter:innen über das Thema sprechen. 👀 Was genau hinter dem Angriff steckt, ist unklar.

    Bisher zwei Folgen verfügbar, erst ab Montag auch frei per #RSS. jeden Montag eine neue Folge.
    deutschlandfunk.de/dark-avenge

    #Überwachung #Privacy #Radio #Deutschlandfunk

  8. Wieder mal eine #Hörempfehlung im Bereich #Podcast: Die Podcast-Reihe #DarkAgent präsentiert die lange Recherche mehrere Journalist:innen zu #OperationTriangulation, einen der umfassendsten und mysteriösesten Angriffe auf Smartphones bzw. iPhones – auch bekannt aus diesem Vortrag beim #37c3: media.ccc.de/v/37c3-11859-oper
    Merkwürdigerweise will #Kaspersky nicht mehr so gern, dass ihre Mitarbeiter:innen über das Thema sprechen. 👀 Was genau hinter dem Angriff steckt, ist unklar.

    Bisher zwei Folgen verfügbar, erst ab Montag auch frei per #RSS. jeden Montag eine neue Folge.
    deutschlandfunk.de/dark-avenge

    #Überwachung #Privacy #Radio #Deutschlandfunk

  9. Group-IB explains precautionary and investigation measures to detect Pegasus spyware Operation Triangulation, Predator spyware, and others on an iOS device. Indicators are from historical reporting. 🔗 group-ib.com/blog/pegasus-spyw

    #Pegasus #spyware #Predator #iOS #OperationTriangulation

  10. The malware injected by #OperationTriangulation is called #TriangleDB. That clearly points to the author of this attack: It *must* be Otto von Schirach!

  11. The malware injected by #OperationTriangulation is called #TriangleDB. That clearly points to the author of this attack: It *must* be Otto von Schirach!

  12. The malware injected by #OperationTriangulation is called #TriangleDB. That clearly points to the author of this attack: It *must* be Otto von Schirach!

  13. The malware injected by #OperationTriangulation is called #TriangleDB. That clearly points to the author of this attack: It *must* be Otto von Schirach!

  14. The malware injected by #OperationTriangulation is called #TriangleDB. That clearly points to the author of this attack: It *must* be Otto von Schirach!

  15. Courtesy of Kaspersky:
    Our experts discovered a flaw in Apple's system, a key factor in the recent #spyware attacks targeting #iPhone users, known as #OperationTriangulation.

    This flaw enables attackers to bypass the iPhone's hardware-based memory protection. Full report ⇒ kas.pr/t3s6

  16. Covered in #securitynow 995 I knew I had to watch this talk I did not catch at the venue.
    media.ccc.de/v/37c3-11859-oper

    Glad I listened to @SGgrc beforehand as he put it into more digestable language and a sober context.
    The talk starts with low-level code deepdives out of the gate. Truetype fonts are turing complete?!

    Thank you @oct0xor kucherin bzvr

    #operationtriangulation #37c3

  17. New Cybersecurity Roundup:

    Someone tried to hack Kaspersky via a complex iPhone attack (“Operation Triangulation”); Jake Appelbaum got (reluctantly) kicked out of CCC; NASA launched a cybersecurity guide for the space industry; India’s Prime Minister Narendra Modi tried to strongarm and retaliate against Apple over hacking warnings, plus early Pandemic Roundup items.

    Link: patreon.com/posts/cybersecurit

    #Cybersecurity #Infosec #Hacking #Hacks #CCC #NASA #Apple #Kaspersky #OperationTriangulation

  18. What the history of OpenBoot, Phrack, Mudge & Solaris, can teach us about the wisdom (or not) of Apple’s building their iPhone security debugging-backdoor-NSA-hack thing

    In the days before people really, really, cared about security — when it was more amazing that mainstream computers worked at all rather than that they offered falsifiable guarantees about privacy and integrity, and most of all in the days before hackerdom decided that it would be great if all the world’s computation ran on “…surely 640Kb is enough for anyone?” glorified MS-DOS personal computers rather than on architectures specifically designed to carry the weight of “big data”… back in those days there was the concept of a monitor.

    By monitor we don’t mean VDU nor LCD screen, but instead that what you considered to be your entire computer operating system was something which could be paused, inspected, poked, amended, restarted or halted, all by a little parasitic computer system which probably polled the device tree and booted it up in the first place. The consequence of the monitor was that — beyond being a mere “boot loader” — you were essentially running your entire operating system kernel under a live debugger on a 24×7 basis.

    This “debugger” was the monitor; sometimes it was separate hardware, sometimes it was just a firmware-level subsystem with which you could interrupt your operating system at any point, and call back into. At Sun Microsystems (in particular, but much the same was available elsewhere) the monitor evolved into a complete and flexible little solution called OpenBoot, which subsequently became a PCI standard (it is/was(?) even in MacOS) and it was massively powerful.

    Unfortunately: with great power comes great responsibility, which (per the first paragraph) people were not really aware of, yet.

    So, in July 1998, Mudge posted in Phrack an article titled “FORTH Hacking on Sparc Hardware” explaining how to use the monitor to change the UID of your shell process to be zero/the root user:

    Fire up the trusty OpenBoot system via L1-A and get the pointer to thecred structure via :ok hex f5e09000 18 + l@ .f5a99858ok goNow, get the effective user id byok hex f5a99858 4 + l@ .309   (309 hex == 777 decimal)ok goOf course you want to change this to 0 (euid root):ok hex 0 f5a99858 4 + l!ok gocheck your credentials!Alliant+ iduid=777(mudge) gid=1(other) euid=0(root)

    tl;dr — press some keys, type a magic incantation in Forth and you become “root”

    Let’s just say that OpenBoot was a very powerful and essential medicine… but that provision of that power caused security side-effects/issues that were not going to go away in any short period of time. An excellent little white paper from GIAC provided a synopsis and context from a few years later, in 2001.

    The technique of elevating user privileges by manually editing system runtime memory is an exploit that can be used to subvert all operating system security measures. This vulnerability is not operating system platform specific and exists in all computer hardware that utilizes a programmable firmware component for hardware control and bootstrapping procedures. This paper will explain this vulnerability as a class of exploit and utilize the SUN Microsystems’ OpenBoot programmable ROM (PROM) and Solaris as a technical example.

    https://www.giac.org/paper/gcih/182/privilege-elevation-system-memory-editing-sun-sparc-platform/101427

    Speaking as one of the people who had to clean up the mess: we/Sun Microsystems should have done a lot more to mitigate the ability of people to get at this powerful medicine; this issue was significant amongst others which drove Sun’s internal security community to create and force the adoption of the “Secure By Default” initiative, and to formalise customer provision and promote adoption of the Solaris Security Toolkit which (amongst many other configuration changes) locked-down several different routes by which the OpenBoot monitor could be exploited.

    From the perspective of 2023: this all should have happened 5, perhaps 10 years before Mudge’s posting, but there was neither the corporate will — nor customer will/expertise — to address the matter at that time.

    So when I look at Apple, and there’s an apparent hardware debugging widget in the memory which can be driven by undocumented means to poke the entire system, for a device which they are literally advertising as robust and secure, my reactions are basically:

    1. Dude…
    2. Dudes…
    3. Dudettes…
    4. What the fuck?
    5. This is history repeating itself…
    6. Like really, what the fuck?
    7. At least when we did it, it was in a world where hardly anyone cared.

    #apple #essay #mudge #openboot #operationTriangulation #sunMicrosystems

    https://alecmuffett.com/article/108789

  19. What the history of OpenBoot, Phrack, Mudge & Solaris, can teach us about the wisdom (or not) of Apple’s building their iPhone security debugging-backdoor-NSA-hack thing

    In the days before people really, really, cared about security — when it was more amazing that mainstream computers worked at all rather than that they offered falsifiable guarantees about privacy and integrity, and most of all in the days before hackerdom decided that it would be great if all the world’s computation ran on “…surely 640Kb is enough for anyone?” glorified MS-DOS personal computers rather than on architectures specifically designed to carry the weight of “big data”… back in those days there was the concept of a monitor.

    By monitor we don’t mean VDU nor LCD screen, but instead that what you considered to be your entire computer operating system was something which could be paused, inspected, poked, amended, restarted or halted, all by a little parasitic computer system which probably polled the device tree and booted it up in the first place. The consequence of the monitor was that — beyond being a mere “boot loader” — you were essentially running your entire operating system kernel under a live debugger on a 24×7 basis.

    This “debugger” was the monitor; sometimes it was separate hardware, sometimes it was just a firmware-level subsystem with which you could interrupt your operating system at any point, and call back into. At Sun Microsystems (in particular, but much the same was available elsewhere) the monitor evolved into a complete and flexible little solution called OpenBoot, which subsequently became a PCI standard (it is/was(?) even in MacOS) and it was massively powerful.

    Unfortunately: with great power comes great responsibility, which (per the first paragraph) people were not really aware of, yet.

    So, in July 1998, Mudge posted in Phrack an article titled “FORTH Hacking on Sparc Hardware” explaining how to use the monitor to change the UID of your shell process to be zero/the root user:

    Fire up the trusty OpenBoot system via L1-A and get the pointer to thecred structure via :ok hex f5e09000 18 + l@ .f5a99858ok goNow, get the effective user id byok hex f5a99858 4 + l@ .309   (309 hex == 777 decimal)ok goOf course you want to change this to 0 (euid root):ok hex 0 f5a99858 4 + l!ok gocheck your credentials!Alliant+ iduid=777(mudge) gid=1(other) euid=0(root)

    tl;dr — press some keys, type a magic incantation in Forth and you become “root”

    Let’s just say that OpenBoot was a very powerful and essential medicine… but that provision of that power caused security side-effects/issues that were not going to go away in any short period of time. An excellent little white paper from GIAC provided a synopsis and context from a few years later, in 2001.

    The technique of elevating user privileges by manually editing system runtime memory is an exploit that can be used to subvert all operating system security measures. This vulnerability is not operating system platform specific and exists in all computer hardware that utilizes a programmable firmware component for hardware control and bootstrapping procedures. This paper will explain this vulnerability as a class of exploit and utilize the SUN Microsystems’ OpenBoot programmable ROM (PROM) and Solaris as a technical example.

    https://www.giac.org/paper/gcih/182/privilege-elevation-system-memory-editing-sun-sparc-platform/101427

    Speaking as one of the people who had to clean up the mess: we/Sun Microsystems should have done a lot more to mitigate the ability of people to get at this powerful medicine; this issue was significant amongst others which drove Sun’s internal security community to create and force the adoption of the “Secure By Default” initiative, and to formalise customer provision and promote adoption of the Solaris Security Toolkit which (amongst many other configuration changes) locked-down several different routes by which the OpenBoot monitor could be exploited.

    From the perspective of 2023: this all should have happened 5, perhaps 10 years before Mudge’s posting, but there was neither the corporate will — nor customer will/expertise — to address the matter at that time.

    So when I look at Apple, and there’s an apparent hardware debugging widget in the memory which can be driven by undocumented means to poke the entire system, for a device which they are literally advertising as robust and secure, my reactions are basically:

    1. Dude…
    2. Dudes…
    3. Dudettes…
    4. What the fuck?
    5. This is history repeating itself…
    6. Like really, what the fuck?
    7. At least when we did it, it was in a world where hardly anyone cared.

    #apple #essay #mudge #openboot #operationTriangulation #sunMicrosystems

    https://alecmuffett.com/article/108789

  20. What the history of OpenBoot, Phrack, Mudge & Solaris, can teach us about the wisdom (or not) of Apple’s building their iPhone security debugging-backdoor-NSA-hack thing

    In the days before people really, really, cared about security — when it was more amazing that mainstream computers worked at all rather than that they offered falsifiable guarantees about privacy and integrity, and most of all in the days before hackerdom decided that it would be great if all the world’s computation ran on “…surely 640Kb is enough for anyone?” glorified MS-DOS personal computers rather than on architectures specifically designed to carry the weight of “big data”… back in those days there was the concept of a monitor.

    By monitor we don’t mean VDU nor LCD screen, but instead that what you considered to be your entire computer operating system was something which could be paused, inspected, poked, amended, restarted or halted, all by a little parasitic computer system which probably polled the device tree and booted it up in the first place. The consequence of the monitor was that — beyond being a mere “boot loader” — you were essentially running your entire operating system kernel under a live debugger on a 24×7 basis.

    This “debugger” was the monitor; sometimes it was separate hardware, sometimes it was just a firmware-level subsystem with which you could interrupt your operating system at any point, and call back into. At Sun Microsystems (in particular, but much the same was available elsewhere) the monitor evolved into a complete and flexible little solution called OpenBoot, which subsequently became a PCI standard (it is/was(?) even in MacOS) and it was massively powerful.

    Unfortunately: with great power comes great responsibility, which (per the first paragraph) people were not really aware of, yet.

    So, in July 1998, Mudge posted in Phrack an article titled “FORTH Hacking on Sparc Hardware” explaining how to use the monitor to change the UID of your shell process to be zero/the root user:

    Fire up the trusty OpenBoot system via L1-A and get the pointer to thecred structure via :ok hex f5e09000 18 + l@ .f5a99858ok goNow, get the effective user id byok hex f5a99858 4 + l@ .309   (309 hex == 777 decimal)ok goOf course you want to change this to 0 (euid root):ok hex 0 f5a99858 4 + l!ok gocheck your credentials!Alliant+ iduid=777(mudge) gid=1(other) euid=0(root)

    tl;dr — press some keys, type a magic incantation in Forth and you become “root”

    Let’s just say that OpenBoot was a very powerful and essential medicine… but that provision of that power caused security side-effects/issues that were not going to go away in any short period of time. An excellent little white paper from GIAC provided a synopsis and context from a few years later, in 2001.

    The technique of elevating user privileges by manually editing system runtime memory is an exploit that can be used to subvert all operating system security measures. This vulnerability is not operating system platform specific and exists in all computer hardware that utilizes a programmable firmware component for hardware control and bootstrapping procedures. This paper will explain this vulnerability as a class of exploit and utilize the SUN Microsystems’ OpenBoot programmable ROM (PROM) and Solaris as a technical example.

    https://www.giac.org/paper/gcih/182/privilege-elevation-system-memory-editing-sun-sparc-platform/101427

    Speaking as one of the people who had to clean up the mess: we/Sun Microsystems should have done a lot more to mitigate the ability of people to get at this powerful medicine; this issue was significant amongst others which drove Sun’s internal security community to create and force the adoption of the “Secure By Default” initiative, and to formalise customer provision and promote adoption of the Solaris Security Toolkit which (amongst many other configuration changes) locked-down several different routes by which the OpenBoot monitor could be exploited.

    From the perspective of 2023: this all should have happened 5, perhaps 10 years before Mudge’s posting, but there was neither the corporate will — nor customer will/expertise — to address the matter at that time.

    So when I look at Apple, and there’s an apparent hardware debugging widget in the memory which can be driven by undocumented means to poke the entire system, for a device which they are literally advertising as robust and secure, my reactions are basically:

    1. Dude…
    2. Dudes…
    3. Dudettes…
    4. What the fuck?
    5. This is history repeating itself…
    6. Like really, what the fuck?
    7. At least when we did it, it was in a world where hardly anyone cared.

    #apple #essay #mudge #openboot #operationTriangulation #sunMicrosystems

    https://alecmuffett.com/article/108789

  21. What the history of OpenBoot, Phrack, Mudge & Solaris, can teach us about the wisdom (or not) of Apple’s building their iPhone security debugging-backdoor-NSA-hack thing

    In the days before people really, really, cared about security — when it was more amazing that mainstream computers worked at all rather than that they offered falsifiable guarantees about privacy and integrity, and most of all in the days before hackerdom decided that it would be great if all the world’s computation ran on “…surely 640Kb is enough for anyone?” glorified MS-DOS personal computers rather than on architectures specifically designed to carry the weight of “big data”… back in those days there was the concept of a monitor.

    By monitor we don’t mean VDU nor LCD screen, but instead that what you considered to be your entire computer operating system was something which could be paused, inspected, poked, amended, restarted or halted, all by a little parasitic computer system which probably polled the device tree and booted it up in the first place. The consequence of the monitor was that — beyond being a mere “boot loader” — you were essentially running your entire operating system kernel under a live debugger on a 24×7 basis.

    This “debugger” was the monitor; sometimes it was separate hardware, sometimes it was just a firmware-level subsystem with which you could interrupt your operating system at any point, and call back into. At Sun Microsystems (in particular, but much the same was available elsewhere) the monitor evolved into a complete and flexible little solution called OpenBoot, which subsequently became a PCI standard (it is/was(?) even in MacOS) and it was massively powerful.

    Unfortunately: with great power comes great responsibility, which (per the first paragraph) people were not really aware of, yet.

    So, in July 1998, Mudge posted in Phrack an article titled “FORTH Hacking on Sparc Hardware” explaining how to use the monitor to change the UID of your shell process to be zero/the root user:

    Fire up the trusty OpenBoot system via L1-A and get the pointer to thecred structure via :ok hex f5e09000 18 + l@ .f5a99858ok goNow, get the effective user id byok hex f5a99858 4 + l@ .309   (309 hex == 777 decimal)ok goOf course you want to change this to 0 (euid root):ok hex 0 f5a99858 4 + l!ok gocheck your credentials!Alliant+ iduid=777(mudge) gid=1(other) euid=0(root)

    tl;dr — press some keys, type a magic incantation in Forth and you become “root”

    Let’s just say that OpenBoot was a very powerful and essential medicine… but that provision of that power caused security side-effects/issues that were not going to go away in any short period of time. An excellent little white paper from GIAC provided a synopsis and context from a few years later, in 2001.

    The technique of elevating user privileges by manually editing system runtime memory is an exploit that can be used to subvert all operating system security measures. This vulnerability is not operating system platform specific and exists in all computer hardware that utilizes a programmable firmware component for hardware control and bootstrapping procedures. This paper will explain this vulnerability as a class of exploit and utilize the SUN Microsystems’ OpenBoot programmable ROM (PROM) and Solaris as a technical example.

    https://www.giac.org/paper/gcih/182/privilege-elevation-system-memory-editing-sun-sparc-platform/101427

    Speaking as one of the people who had to clean up the mess: we/Sun Microsystems should have done a lot more to mitigate the ability of people to get at this powerful medicine; this issue was significant amongst others which drove Sun’s internal security community to create and force the adoption of the “Secure By Default” initiative, and to formalise customer provision and promote adoption of the Solaris Security Toolkit which (amongst many other configuration changes) locked-down several different routes by which the OpenBoot monitor could be exploited.

    From the perspective of 2023: this all should have happened 5, perhaps 10 years before Mudge’s posting, but there was neither the corporate will — nor customer will/expertise — to address the matter at that time.

    So when I look at Apple, and there’s an apparent hardware debugging widget in the memory which can be driven by undocumented means to poke the entire system, for a device which they are literally advertising as robust and secure, my reactions are basically:

    1. Dude…
    2. Dudes…
    3. Dudettes…
    4. What the fuck?
    5. This is history repeating itself…
    6. Like really, what the fuck?
    7. At least when we did it, it was in a world where hardly anyone cared.

    #apple #essay #mudge #openboot #operationTriangulation #sunMicrosystems

    https://alecmuffett.com/article/108789

  22. Imagine discovering a #0click attack targeting #iPhones of your colleagues & managing to capture 4 #0Day & a spyware with mind-blowing 🤯 capabilities.

    At #37c3 - @oct0xor, @bzvr_ & @kucher1n will tell you everything about the “#OperationTriangulation”.👇

    media.ccc.de/v/37c3-11859-oper

  23. Imagine discovering a #0click attack targeting #iPhones of your colleagues & managing to capture 4 #0Day & a spyware with mind-blowing 🤯 capabilities.

    At #37c3 - @oct0xor, @bzvr_ & @kucher1n will tell you everything about the “#OperationTriangulation”.👇

    media.ccc.de/v/37c3-11859-oper

  24. #OperationTriangulation research uncovers new details of fantastic attack chain.

    A zero click RCE, chaining four zero days over four years was one hell of an achievement. Yevgeny “Eugene” Valentinovich Kaspersky’s team call it “definitely the most sophisticated attack chain we have ever seen.”

    But does that prove #Apple colluded with the #NSA? In #SBBlogwatch, we DO believe the hype. At @TechstrongGroup’s @SecurityBlvd: securityboulevard.com/2023/12/

  25. 4-year campaign backdoored iPhones using possibly the most advanced exploit ever - Enlarge (credit: Tero Vesalainen)

    Researchers on Wednesday pre... - arstechnica.com/?p=1992873 #operationtriangulation #security #iphones #malware #spyware #biz#apple #0day

  26. Die Spyware-Angriffe der #OperationTriangulation, die seit 2019 auf #iPhones abzielen, nutzten undokumentierte Funktionen in Apple-Chips, um hardwarebasierte Sicherheitsvorkehrungen zu umgehen: winfuture.de/news,140330.html?

  27. "Operation Triangulation: What You Get When Attack iPhones of Researchers"

    Analysis of a highly sophisticated spyware that had been around for years without anyone noticing. Very technical talk, but also higher level insights.

    #37C3Recommendation #37C3 #OperationTriangulation #iPhone #Smartphone #APT #AdvancedPersistentThreat

    events.ccc.de/congress/2023/hu

  28. "Operation Triangulation: What You Get When Attack iPhones of Researchers"

    Analysis of a highly sophisticated spyware that had been around for years without anyone noticing. Very technical talk, but also higher level insights.

    #37C3Recommendation #37C3 #OperationTriangulation #iPhone #Smartphone #APT #AdvancedPersistentThreat

    events.ccc.de/congress/2023/hu

  29. Cybersecurity firm @kaspersky has shed light on an ongoing campaign known as #operationtriangulation, targeting iOS devices.

    By exploiting a zero-click iMessage vulnerability, attackers gain root privileges and execute code on compromised iPhones.

    Update your iOS device now!