The engineering part of social engineering<br />aluc# <br />or why just lying your way in don't get you anywhere.<br />
I’m Aluc<br />I’m a old hacker who loves the blood of your network<br />
Preface:<br />
Needed Skillset:-physical		-logical-Customer Preparation	-theoretical models of attack	-check the customer needs by his bu...
Needed physical/psychical Skillset:-understanding of craftsmanshipideal life experiences as electrician 	telephone cable G...
Example Skills:<br />
Example Skills:<br />
What is your first impression?-Cloths Civil/Uniform type -Body type-Gender-Ethnic-Manners/Discipline-Physical Markings-Sme...
Everyone talks about NLP what is this:NLP is a communications model Created in the 	early 70’s by John GrinderandRichard B...
The Modeling: 	in this Process you want to find 	out how 	your Brain operates by 	analyzing the 	pattern of verbal 	and no...
Understanding keywords and differ between Attributes and states:-A humans Brain can process about 	100 trillion terraflops...
How do we use this:	-listen in conversations to keywords	like “stress” “freedom” “love” etc-find out in which state the 	p...
Micro Expressions:Based on the System which Dr.Friesen developed, we can divide about 1000 unique facial expressions which...
Micro Expressions:here some Charts from Dr.Lightman:<br />
Convert Attributes into States:-try to generate and feel states for 	yourself	-try to generate Statesfrom other 	people by...
Intelligence Gathering before 1th customer meeting:internet search:	-Maltego-theHarvester	-BundesAnzeiger	-http://www.onst...
Meet the Client:	-find out what his business is	-find out about the companies 	hierarchy	-customer relations-vendor relati...
Treat Modeling:	-asset (resources which can become 	targets) -threat-vulnerability	-attack-countermeasures1.	identify the ...
Treat Modeling:	STRIDE ­ Model	-Spoofing Identity 	-Tampering with Data	-Repudiation	-Information Disclosure	-Denial of Se...
Treat Modeling:DREAD ­ Model-Damage Potential-Reproducibility-Exploitability-Affected Users-Discoverability<br />
Treat Modeling:<br />
The Assesment:-the Storyboard	-Infiltration	-Find & fetch the data	-Exfiltratethe data-backup plan-Writing report	-Busines...
Infiltration:	-tailgating / piggybacking	-steal Fingerprint	-use of RFID Skimmer	-Copy entry badges ie. With a 	proxmark I...
Example Infiltration Hardware:<br />
Finding and fetching Data:	-Printer	-Spearfishing	-Dumpster diving	-0x41414141	-Keylogger	-l0pthcrack		<br />
Exfiltrate Data:	-USB Key	-printout in Trash	-over the Net	-photo<br />
Thanx for listening see/hear me at: http:// aluc.tv<br />
Upcoming SlideShare
Loading in...5
×

The engineering part of social engineering, or why just lying your way in don't get you anywhere.

623

Published on

All the talks i saw about SE so far just showed which good SE's the speakers are. I try to do another approach, what if i get in and don't know what to do then. The talk is about the reconn. before the assessment, the different approaches of SE. Which techniques can one use, how to do a proper intel. and what is useful. How things work and more important why. Which skill set should one have before entering a engagement. And last but not least how do one counter a SE attack.



Preface:



Needed Skillset:

-physical (ie.NLP)

-logical Customer Preparation:

-theoretical models of attack

-check customer needs by his business

-Contract

Preparation & Reconnaissance:

-threat modeling

-physical

-logical

Project Planing:

-Storyboard

-the target

-infiltration

-fetching data/reaching the target

-exfiltrate

-backup plans

Infiltration:

Find & fetch the data:

Exfiltrate the data:

Writing report:

Business impact analyses:

customer meeting:

Published in: Technology
1 Comment
1 Like
Statistics
Notes
  • You wan't see the multimedia parts of the presentation, check the video from the talk!
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
623
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
6
Comments
1
Likes
1
Embeds 0
No embeds

No notes for slide
  • 1. Identifikation der „Assets“ bzw. SicherheitszieleAm Anfang sind normalerweise Anforderungen, Sicherheitsrichtlinien, Normen oder sonstige Vorschriften gegeben, welche auf Schlüsselziele abgebildet werden können. Diese klaren Ziele helfen bei der Aufgabenverteilung und –übersicht. Während der Entwicklungsphase istes durchaus möglich, dass sich die Anforderungen an die Software ändern. Jedes mal, wenn neue Informationen verfügbar werden, sollte man sie gegen die aktuell erforderlichen Richtlinien abgleichen und das über weitere Vorgehen entscheiden.2. Übersicht der ArchitekturEinfache Diagramme und Tabellen ergeben einen groben Überblick über die Softwarearchitektur. Wichtige Anwendungsfälle (engl. „usecases“) und verwendete Technologien bieten Charakteristika, welche helfen, Bedrohungen zu identifizieren.3. Dekomposition der ArchitekturHier wird die Architektur detailliert untersucht. Bsp. wird bei Webanwendungen das zugrunde liegende Netzwerk und die Infrastruktur des Hosts betrachtet. Es werden Vertrauensgrenzen gesetzt und mittels Datenflussdiagrammen interne Abläufe nachvollziehbar dargestellt. So kann man auch Einstiegspunkte des Nutzers in die Software aufzeigen.4. Bedrohungen herausstellenAn Hand der Sicherheitsrichtlinien, dem gewonnenem Architekturwissen und allgemein bekannten „Threats“ kann man nun herausfinden, welche Bedrohungen für das System realistisch sind (siehe „STRIDE“‐Modell). Danach müssen diese natürlich bewertet werden, damit man jeder relevanten Bedrohung ihren angemessenen Aufmerksamkeitsgrad zuordnen kann (siehe „DREAD“‐Modell). Parallel dazu ist eine gute Dokumentation unentbehrlich. Diese Daten könnten in ein Bugtracking‐System eingepflegt und direkt dessen Reportfunktionalitäten genutzt werden.5. Sicherheitslücken findenDie identifizierten Bedrohungen müssen mit gegebenen Schwachstellen in Verbindung gebracht werden. Auch hier können allgemein gültige Informationen über Schwächen in verwendeten Technologien hilfreich sein, um vorliegende Sicherheitslücken zu finden.
  • 1. Identifikation der „Assets“ bzw. SicherheitszieleAm Anfang sind normalerweise Anforderungen, Sicherheitsrichtlinien, Normen oder sonstige Vorschriften gegeben, welche auf Schlüsselziele abgebildet werden können. Diese klaren Ziele helfen bei der Aufgabenverteilung und –übersicht. Während der Entwicklungsphase istes durchaus möglich, dass sich die Anforderungen an die Software ändern. Jedes mal, wenn neue Informationen verfügbar werden, sollte man sie gegen die aktuell erforderlichen Richtlinien abgleichen und das über weitere Vorgehen entscheiden.2. Übersicht der ArchitekturEinfache Diagramme und Tabellen ergeben einen groben Überblick über die Softwarearchitektur. Wichtige Anwendungsfälle (engl. „usecases“) und verwendete Technologien bieten Charakteristika, welche helfen, Bedrohungen zu identifizieren.3. Dekomposition der ArchitekturHier wird die Architektur detailliert untersucht. Bsp. wird bei Webanwendungen das zugrunde liegende Netzwerk und die Infrastruktur des Hosts betrachtet. Es werden Vertrauensgrenzen gesetzt und mittels Datenflussdiagrammen interne Abläufe nachvollziehbar dargestellt. So kann man auch Einstiegspunkte des Nutzers in die Software aufzeigen.4. Bedrohungen herausstellenAn Hand der Sicherheitsrichtlinien, dem gewonnenem Architekturwissen und allgemein bekannten „Threats“ kann man nun herausfinden, welche Bedrohungen für das System realistisch sind (siehe „STRIDE“‐Modell). Danach müssen diese natürlich bewertet werden, damit man jeder relevanten Bedrohung ihren angemessenen Aufmerksamkeitsgrad zuordnen kann (siehe „DREAD“‐Modell). Parallel dazu ist eine gute Dokumentation unentbehrlich. Diese Daten könnten in ein Bugtracking‐System eingepflegt und direkt dessen Reportfunktionalitäten genutzt werden.5. Sicherheitslücken findenDie identifizierten Bedrohungen müssen mit gegebenen Schwachstellen in Verbindung gebracht werden. Auch hier können allgemein gültige Informationen über Schwächen in verwendeten Technologien hilfreich sein, um vorliegende Sicherheitslücken zu finden.
  • 1. Identifikation der „Assets“ bzw. SicherheitszieleAm Anfang sind normalerweise Anforderungen, Sicherheitsrichtlinien, Normen oder sonstige Vorschriften gegeben, welche auf Schlüsselziele abgebildet werden können. Diese klaren Ziele helfen bei der Aufgabenverteilung und –übersicht. Während der Entwicklungsphase istes durchaus möglich, dass sich die Anforderungen an die Software ändern. Jedes mal, wenn neue Informationen verfügbar werden, sollte man sie gegen die aktuell erforderlichen Richtlinien abgleichen und das über weitere Vorgehen entscheiden.2. Übersicht der ArchitekturEinfache Diagramme und Tabellen ergeben einen groben Überblick über die Softwarearchitektur. Wichtige Anwendungsfälle (engl. „usecases“) und verwendete Technologien bieten Charakteristika, welche helfen, Bedrohungen zu identifizieren.3. Dekomposition der ArchitekturHier wird die Architektur detailliert untersucht. Bsp. wird bei Webanwendungen das zugrunde liegende Netzwerk und die Infrastruktur des Hosts betrachtet. Es werden Vertrauensgrenzen gesetzt und mittels Datenflussdiagrammen interne Abläufe nachvollziehbar dargestellt. So kann man auch Einstiegspunkte des Nutzers in die Software aufzeigen.4. Bedrohungen herausstellenAn Hand der Sicherheitsrichtlinien, dem gewonnenem Architekturwissen und allgemein bekannten „Threats“ kann man nun herausfinden, welche Bedrohungen für das System realistisch sind (siehe „STRIDE“‐Modell). Danach müssen diese natürlich bewertet werden, damit man jeder relevanten Bedrohung ihren angemessenen Aufmerksamkeitsgrad zuordnen kann (siehe „DREAD“‐Modell). Parallel dazu ist eine gute Dokumentation unentbehrlich. Diese Daten könnten in ein Bugtracking‐System eingepflegt und direkt dessen Reportfunktionalitäten genutzt werden.5. Sicherheitslücken findenDie identifizierten Bedrohungen müssen mit gegebenen Schwachstellen in Verbindung gebracht werden. Auch hier können allgemein gültige Informationen über Schwächen in verwendeten Technologien hilfreich sein, um vorliegende Sicherheitslücken zu finden.
  • 1. Identifikation der „Assets“ bzw. SicherheitszieleAm Anfang sind normalerweise Anforderungen, Sicherheitsrichtlinien, Normen oder sonstige Vorschriften gegeben, welche auf Schlüsselziele abgebildet werden können. Diese klaren Ziele helfen bei der Aufgabenverteilung und –übersicht. Während der Entwicklungsphase istes durchaus möglich, dass sich die Anforderungen an die Software ändern. Jedes mal, wenn neue Informationen verfügbar werden, sollte man sie gegen die aktuell erforderlichen Richtlinien abgleichen und das über weitere Vorgehen entscheiden.2. Übersicht der ArchitekturEinfache Diagramme und Tabellen ergeben einen groben Überblick über die Softwarearchitektur. Wichtige Anwendungsfälle (engl. „usecases“) und verwendete Technologien bieten Charakteristika, welche helfen, Bedrohungen zu identifizieren.3. Dekomposition der ArchitekturHier wird die Architektur detailliert untersucht. Bsp. wird bei Webanwendungen das zugrunde liegende Netzwerk und die Infrastruktur des Hosts betrachtet. Es werden Vertrauensgrenzen gesetzt und mittels Datenflussdiagrammen interne Abläufe nachvollziehbar dargestellt. So kann man auch Einstiegspunkte des Nutzers in die Software aufzeigen.4. Bedrohungen herausstellenAn Hand der Sicherheitsrichtlinien, dem gewonnenem Architekturwissen und allgemein bekannten „Threats“ kann man nun herausfinden, welche Bedrohungen für das System realistisch sind (siehe „STRIDE“‐Modell). Danach müssen diese natürlich bewertet werden, damit man jeder relevanten Bedrohung ihren angemessenen Aufmerksamkeitsgrad zuordnen kann (siehe „DREAD“‐Modell). Parallel dazu ist eine gute Dokumentation unentbehrlich. Diese Daten könnten in ein Bugtracking‐System eingepflegt und direkt dessen Reportfunktionalitäten genutzt werden.5. Sicherheitslücken findenDie identifizierten Bedrohungen müssen mit gegebenen Schwachstellen in Verbindung gebracht werden. Auch hier können allgemein gültige Informationen über Schwächen in verwendeten Technologien hilfreich sein, um vorliegende Sicherheitslücken zu finden.
  • 1. Identifikation der „Assets“ bzw. SicherheitszieleAm Anfang sind normalerweise Anforderungen, Sicherheitsrichtlinien, Normen oder sonstige Vorschriften gegeben, welche auf Schlüsselziele abgebildet werden können. Diese klaren Ziele helfen bei der Aufgabenverteilung und –übersicht. Während der Entwicklungsphase istes durchaus möglich, dass sich die Anforderungen an die Software ändern. Jedes mal, wenn neue Informationen verfügbar werden, sollte man sie gegen die aktuell erforderlichen Richtlinien abgleichen und das über weitere Vorgehen entscheiden.2. Übersicht der ArchitekturEinfache Diagramme und Tabellen ergeben einen groben Überblick über die Softwarearchitektur. Wichtige Anwendungsfälle (engl. „usecases“) und verwendete Technologien bieten Charakteristika, welche helfen, Bedrohungen zu identifizieren.3. Dekomposition der ArchitekturHier wird die Architektur detailliert untersucht. Bsp. wird bei Webanwendungen das zugrunde liegende Netzwerk und die Infrastruktur des Hosts betrachtet. Es werden Vertrauensgrenzen gesetzt und mittels Datenflussdiagrammen interne Abläufe nachvollziehbar dargestellt. So kann man auch Einstiegspunkte des Nutzers in die Software aufzeigen.4. Bedrohungen herausstellenAn Hand der Sicherheitsrichtlinien, dem gewonnenem Architekturwissen und allgemein bekannten „Threats“ kann man nun herausfinden, welche Bedrohungen für das System realistisch sind (siehe „STRIDE“‐Modell). Danach müssen diese natürlich bewertet werden, damit man jeder relevanten Bedrohung ihren angemessenen Aufmerksamkeitsgrad zuordnen kann (siehe „DREAD“‐Modell). Parallel dazu ist eine gute Dokumentation unentbehrlich. Diese Daten könnten in ein Bugtracking‐System eingepflegt und direkt dessen Reportfunktionalitäten genutzt werden.5. Sicherheitslücken findenDie identifizierten Bedrohungen müssen mit gegebenen Schwachstellen in Verbindung gebracht werden. Auch hier können allgemein gültige Informationen über Schwächen in verwendeten Technologien hilfreich sein, um vorliegende Sicherheitslücken zu finden.
  • The engineering part of social engineering, or why just lying your way in don't get you anywhere.

    1. 1. The engineering part of social engineering<br />aluc# <br />or why just lying your way in don't get you anywhere.<br />
    2. 2. I’m Aluc<br />I’m a old hacker who loves the blood of your network<br />
    3. 3. Preface:<br />
    4. 4. Needed Skillset:-physical -logical-Customer Preparation -theoretical models of attack -check the customer needs by his business -Contract<br />
    5. 5. Needed physical/psychical Skillset:-understanding of craftsmanshipideal life experiences as electrician telephone cable Guy computer Mechanic-lock picking-in hostile environment Physical Security-good rhetoric-understanding of the person you approach-a understanding of human psychology-NLPideal Hypnosis <br />
    6. 6. Example Skills:<br />
    7. 7. Example Skills:<br />
    8. 8. What is your first impression?-Cloths Civil/Uniform type -Body type-Gender-Ethnic-Manners/Discipline-Physical Markings-Smell-Teeth-Hands<br />
    9. 9. Everyone talks about NLP what is this:NLP is a communications model Created in the early 70’s by John GrinderandRichard Bandler The basisoftheirworkaretheanalysesoftheworkofthetherapists Fritz Perls, Virginia Satir and Milton H. Erickson The N stands for the flow of Neurologic processes in the Human Brain The L stands linguistic what is our capability to speakThe P stands for programming what means the change of the “inner Program” of a Human<br />
    10. 10. The Modeling: in this Process you want to find out how your Brain operates by analyzing the pattern of verbal and nonverbal communication. The outcome can be used for step by step guides to transfer skills from one person to another Example: “From the Basement to the Bedroom” a Pickup guide by Chris Nickerson<br />
    11. 11. Understanding keywords and differ between Attributes and states:-A humans Brain can process about 100 trillion terraflops -Your sensors getting 10.000 bit/s -from this 10.000 bits are about 40 being processedThat makes us to “make up” our very own version of this world.<br />
    12. 12. How do we use this: -listen in conversations to keywords like “stress” “freedom” “love” etc-find out in which state the person is vs his/her believing-pay attention to micro expressions -understand the difference between a state and a attribute “he feels” vs “he has”<br />
    13. 13. Micro Expressions:Based on the System which Dr.Friesen developed, we can divide about 1000 unique facial expressions which are exposed by the neurological connection between the emotions and the 43 muscles we have in the face. This can be used to find out if a person lies at you.One should not underestimate what you can see in the eyes.With a bit of training you can see if a person sees a video picture in the "mind's eye" (Visual) or is listening to an internal recording(Auditory), or if she/he is concentrating on feelings (Kinaesthetic)<br />
    14. 14. Micro Expressions:here some Charts from Dr.Lightman:<br />
    15. 15. Convert Attributes into States:-try to generate and feel states for yourself -try to generate Statesfrom other people by using the “right” words -find out when these states are appropriate - find the right timing to use these statesDon’t forget: From the 2Mio Bit/s messages you get in you can only deal with ±7 at one time<br />
    16. 16. Intelligence Gathering before 1th customer meeting:internet search: -Maltego-theHarvester -BundesAnzeiger -http://www.onstrat.com/osint/-whois -Social Media visit the Place ie. As customer -building-video surveillance-entry systems -security/alarm systems <br />
    17. 17. Meet the Client: -find out what his business is -find out about the companies hierarchy -customer relations-vendor relations<br />
    18. 18. Treat Modeling: -asset (resources which can become targets) -threat-vulnerability -attack-countermeasures1. identify the security objectives2. get a application overview3. decompose the architecture4. identify threats 5. identify vulnerabilities<br />
    19. 19. Treat Modeling: STRIDE ­ Model -Spoofing Identity -Tampering with Data -Repudiation -Information Disclosure -Denial of Service -Elevation of Privilege<br />
    20. 20. Treat Modeling:DREAD ­ Model-Damage Potential-Reproducibility-Exploitability-Affected Users-Discoverability<br />
    21. 21. Treat Modeling:<br />
    22. 22. The Assesment:-the Storyboard -Infiltration -Find & fetch the data -Exfiltratethe data-backup plan-Writing report -Business impact analyses -customer meeting -Customer Trainings<br />
    23. 23. Infiltration: -tailgating / piggybacking -steal Fingerprint -use of RFID Skimmer -Copy entry badges ie. With a proxmark III -Car key skimmer -drop 32GB USB Key -pick Locks-entry as Vendor-entry as Client<br />
    24. 24. Example Infiltration Hardware:<br />
    25. 25.
    26. 26. Finding and fetching Data: -Printer -Spearfishing -Dumpster diving -0x41414141 -Keylogger -l0pthcrack <br />
    27. 27. Exfiltrate Data: -USB Key -printout in Trash -over the Net -photo<br />
    28. 28. Thanx for listening see/hear me at: http:// aluc.tv<br />
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×