Networkforensic

Threat hunting

ADFS logon dashboard now in Security Onion

08 Juli 2020  - Blog Post # 768

ADFS
Da jeg ikke kunne spotte når en pc lavede NTLM auth outbound hen over https. Har jeg oprettet et dashboard der kigger efter når dette sker. Det kræver dog man ændre en Local eller AD Security Policy før det virker i Windows.


Tjek det ud her

 

Modbus IDS rules

28 Juni 2020  - Blog Post # 767

Modbus
Modbus protokollen er noget der benyttes i rigtig mange IOT netværk. Jeg gennemgik en bunke af IDS rules jeg tilføjede, hvori modbus var en det af det. I denne rule pack har jeg nu tilføjet flere modbus rules til detection af commands, der kan benyttes til DOS attack imod modbus enabled IOT enheder. Man bør holde et vågent øje med disse.

Beskrivelse:
En angriber kan sende "restart" commands til enheder og derved holde enheder nede.

Wireshark displayfilter - Restart
modbus.diagnostic_code == 1

En angriber kan sende "Force Listen Only" der vil bevirke at enheder ikke længere vil kommunikere med andre enheder og derved skabe katestrofale uoverskuelige følger.

Wireshark displayfilter - Force Listen Only
modbus.diagnostic_code == 4

En angriber vil typisk foretage "Read Holding Registers" for at gennemskue hvilke commands der kan modificeres og sendes til enheder før et angreb gennemføres.

Wireshark displayfilter - Read Holding Registers
modbus.func_code == 3

IDS Rule frigivet
Disse er lavet forholdvis løst og man bør tilpasse en smule på Home og External networks, alt efter hvordan ens netværk er opsat. Igen kunne jeg ikke finde noget der var frigivet der gjorde mig i standt til at finde dette.
Frigivet under "Modbus identification rules - SID:120000001 - SID:120001000" i NF-SCADA.Rules.......Happy hunting

 

SMBleed  CVE-2020-1206

16 Juni 2020  - Blog Post # 766

SMBleed
SMBleed er endnu en i rækken af sårbarheder i SMB 3. Den bygger ret meget på SMBGhost. Det er yderst avanceret arbejde der er lagt i at finde denne sårbarhed. I den forbindelse har vi ledt højt og lavt efter detection til udnyttelsen af denne sårbarhed, men vi har ikke fundet nogen der har lavet noget til det. 
Du kan læse mere om sårbarheden her.



Detection
Den ser på den payload der bliver sendt til systemerne. Min kollega Kasper Blåbjerg har brugt en del tid på at ændre i source koden til denne, for at se hvor der kunne ændres i indholdet for at undgå detection. Men der kan sådan set kun lige ændres i fil navnt og payload størrelse på memory dumpet. Men der kan sikkert ændres i det såfremt man har tid nok til at teste.

Wireshark display filter.
Følgende Wireshark display filter kan benyttes. Dette er også frigivet i en ny SMB profile til Wireshark her
smb2.header.comp_transform.data contains 60:0a:46:02:fe:53:4d:42:40:00

IDS Rule frigivet
Kigger efter SMB 3.1.1 TCP port 445 og 10 bytes fra starten af payloaden. Happy hunting.

 

Hawkeye Trojan and keylogger

03 Juni 2020  - Blog Post # 765

Hawkeye Detection
Har netop tilføjet detection for Hawkeye Trojan og Keylogger til mit frigivet malware monitor dashboard. Endnu engang er det forholdvis nemt at tilføje en hel familie af malware og finde dem hver gang.



Gammeldags eller ej ?
Jeg må efterhånden sige at jeg har fundet metodikken til at dette kan lade sig gøre næsten hver gang jeg lige finder tid til at lave det. Der er dog nogle forudsætninger man lige skal kende og lidt løsninger, man selv skal have kørende så er det til at finde hele botnet familier, der benytter sig af krypteret forbindelser. Høre man til dem der endeløst jagter domæner og IP adresser på det område, vil jeg efterhånden kalde det for lidt gammeldags...

Sysmon DeleteFile funktion

21 May 2020  - Blog Post # 764

Sysmon v11.0
Sysmon er kommet med en ny FileDelete funktion. (Event_ID 23) Denne kan fange filer som eks malware sletter, eller hvis nogen forsøger at wipe (schredde) filer fra et system. Så kan den også fange disse inden de bliver slettet. Så alene sysmon er nu oppe på 82 beskrevet MITRE metodikker den kan overvåge.

Security Onion
Jeg har fået dette implementeret ind i Security Onion. Jeg har frigivet dashboards til alle sysmon's funktioner inklusiv de udokumenteret og nu også med event_id 23. - Tjek det ud her

Er det brugbart ?
Måden hvorpå filer bliver gemt er direkte ned i en hidden (som i hidden folder) folder. Man kan ikke ummidelbart få adgang til denne, uden der eks benyttes andre tools for at se filer de filer der er blevet slettet. Det betyder at c drevet kan blive fyldt op med filer. Man skal derfor være meget opmærksom på hvad man vælger at opsamle fra systemer.

Til overvåget systemer hvor man eks laver analyser af malware, kan det være en rigtig god ide at fange filer bredt fra et system som bliver slettet.

Det kan eks også være brugbart i situationer hvor en medarbejder er opsagt eller tilsvarende, såfremt man vil være sikker på at kritiske filer ikke bliver slettet.

MITRE
Sysmon er nu oppe på 82 beskrevet MITRE metodikker den kan overvåge. Hvilket i sig selv er rigtig godt resultatet.

Frigivet
Jeg har frigivet sysmon config filen med nogle simple metodikker som typisk kan bruges af hacker til at slette filer fra systemer. MEN jeg anbefaler kraftig man selv lige kigger sysmon config filen igennem for hvad der giver mening for dig/jer at lave denne form for opsamling af slettet filer. For jeg mener ikke ummidelbart det giver mening på alle systemer.

Som et eksempel oprettede jeg en monitor der kiggede på alle filer slettet fra %temp%. Det er eks IKKE en god ide. Bare noget som VmWare sletter helt vildt mange filer fra temp folders. Jeg Vil tro at man på et par dage kan fylde harddiske op med "ubrugelige" filer meget hurtigt.

Men min config fil giver forholdsvis god mening over hvad man lige kan. I skrivende stund er Sysinternals dokumentation lidt dårligt dokumenteret og jeg anbefaler man kigger youtube filmen igennem fra Mark Russinovich. 

Made for:
Security Onion - 16.04.6.6
Kibana 6.8.8 management
Winlogbeat - 6.8.8
Sysmon - 11.0

 

Udvikling af Coronavaccine skal beskyttes

14 May 2020  - Blog Post # 763

Udvikling af ny coronavaccine
Her kommer der en VIGTIG  forudsigelse.

Virksomheder der udvikler coronavaccine skal være yderst vågne overfor fremmede stater, aktører der ønsker at stjælpe oplyninger omkring udviklingen af coronavaccine.

Target
Det ligger så højt på target lister lige nu, fordi mennesker dør, samfund er lukket ned mm, i kender selv historien.

Virksomheden (landet) der kommer først med en coronavaccine, vil tjene uanet mængder af penge og tilførelsen at penge til netop en coronavaccine udvikling er enorm. Derfor kan det betale sig at stjæle disse oplysninger fra andre, da det er meget billigerer.

I går fortalte jeg en kollegae om netop dette og hvorfor det er sådan. I dag beskylder FBI allerede kina for at forsøge at bryde ind i virksomheder der udvikler coronavaccine for netop at stjæle oplysningerne. Se CNN. eller Cyberscoop

IT-Sikkerhed har aldrig været mere vigtig
Jeg kan kun anbfeale at virksomheder er der er involveret i coronavaccine udvikling  er meget vågen overfor for at beskytte data der er relateret til udviklingen af coronavaccine. Man skal være klar til at tage unormale skridt i brug for at beskytte netop de data.

Anbefaling
Jeg anbefaler virkelig man tager kontakt til hele den danske sikkerheds industri for at få lavet tjek på områder, hvor data relateret til denne udvikling bliver gået efter.

Det er virkelig vigtig at disse områder eksempelvis ikke har nogen form for Internet adgang og at den fysiske sikring til områder er på det højeste.

Ingen fomer for udstyr med eks adgang til mail må befinde sig i disse områder. Ingen internetadgang, Fysisk sikring med forhøjet kontrol af hvem der har adgang til disse områder skal være mere end meget høj. SLET ingen former for cloud løsninger må benyttes, bare for lige at nævne nogen.

 

Dashboards and winlogbeat update

12 May 2020  - Blog Post # 762

Security Onion dashboards
Dashboards and Winlogbeat has been updated for Security Onion 16.04.6.6.
Check them out

Made for:
Security Onion - 16.04.6.6
Kibana 6.8.8 management
Winlogbeat - 6.8.8
Sysmon - 10.0.4.2

 

Autopsy digital forensics

07 May 2020  - Blog Post # 761

Autopsy
I mit daglige arbejde bruger jeg dagligt rigtig mange forskellige forensics tools. Et af disse er Autopsy. Jeg vil gerne slå et slag for netop Autopsy, da de efterhånden har vosket sig mere end rigtig godt. Det har fået rigtig mange nye funktioner indbygget jeg kan kun anbefale man tjekke det ud.

Træning
Er du hurtig er der pt gratis træning frem til 15 Maj 2020.

Jeg har selv lige gennemgået deres træning og der er mange ting jeg ikke vidste det rent faktisk kan og gør. Det har bla altid få lidt skyld for at være lidt langsomt, MEN med den rigtige træning, så kan man også finde ud af sætte det rigtigt op så det langt fra er tilfældet.

MISP
Bemærk at ved at være medlem hos The Danish MISP User Group/Community der kan man hente bla MD5 hashes, der kan benyttes direkte ind i forensic sager man arbejder på. Dette er dog lige nu manuelt, de skal oprettes.

MEN jeg håber lidt på der måske kan oprettes en central MD5 hash database der kan benyttes centralt, så behøver  man "bare" at pege sin Autopsy direkte ud på denne og derved benytte Autopsy med opdateret informationer hele tiden. (Lige nu kun et håb)




 

 

Geo-blokeringer på mailservers

08 April 2020  - Blog Post # 759

Geo Blocking
For første gang har jeg forsøgt mig med egentelig geo blokeringer på mailsystemer i drift. Jeg har gennemgået alle log filer for forskellige typer angreb. Det meste af det er SPAM som forventet, men også mange forsøg på eks misbrug af SPF, Bruteforce attacks, Phishing, som er den "normale" dagligdag på mailsystemer.

Corona krisen
Efter Corona krisen gik i gang, er det det exploderet med netop phishing, SPAM, og mange typer attacks imod netop mail systemer og brugerne. Dette gav mig den egentelige grund til at indføre Geo blokeringer.

Anbefalet
Da jeg ikke driver forretning i Rusland, Kina, Tyrkiet,  mm er disse blandt dem jeg har blokeret.  Jeg kan kun anbefale man indføre det på egne systemer, der hvor det giver mening. Antallet at angreb og bla SPAM er næsten faldet til et rungende NUL.

Bare når jeg ser få faldet i trafik mængder imod mailsystemerne, så er det ret betragteligt. Skulle det ske at noget uventet bliver blokeret, så har jeg allerede taget højde ved simpelt at lave Firewall Allow regler der allerede er gjort klar til at tillade enkelte MX'er. Men forventer ikke at skulle gøre ret meget brug af det.

Benytter man O365 er man vel stadig LOST tænker jeg, da man ikke får denne mulighed. Her kan man leve i den evige uvished.

Vil man selv igang og ikke har en FW der har indbygget Geo blokerings muligheder bør man kaste et blik denne vej
https://www.countryipblocks.net/acl.php

Jeg behøver vel ikke fortælle her hvornår Geo blokeringen gik igang  ???



 

Windows PowerShell

28 Marts 2020  - Blog Post # 758

Windows PowerShell
Har nu fået lavet et Windows PowerShell dashboard til Security Onion. Har dog stadig et PowerShell dashboard der er lavet til Sysmon logs, men efter ønske har jeg også lavet et til Wndows eventlogs. Fordi nogen ikke kan/vil køre Sysmon. Det er frigivet her

Malware hunting dashboard:
Efterhånden som jeg positivt kan identificere malware der benytter sig af TLS eller SSH forbindelser opretter jeg detection basseret på JA3 / JA3S / HASSH.

Disse dækker nu følgende malware familier
Emotet, Quakbot, Tofsee, Gozi, Cobalt Strike - Win10 to Kali, Metasploit - Win10 to Kali, TrickBot, Dridex, Gootkit
JBifrost, IcedID (BokBOT), Python used with Empire.

Jeg har nu frigivet 50 dashboards og hele 413 Object til Security Onion.

 

 

 

Crimson Trojan RAT

22 Marts 2020  - Blog Post # 757

Crimson Trojan RAT - APT tool
Fik fat i en version af Crimson RAT som bliver benyttet af bla APT-36. Det er en ren java applikation, som er cross platform. Det er dog første gang jeg ser en RAT der er så orienteret i forhold til at kunne inficerer Android mobil telefoner. Den bliver benyttet i forhold infections som pt er Corona virus relateret.


Crimson - Encryption

Denne kan køre på alle porte efter eget valg, hvilket gør den god at skjule med forskellige former for kryptering der kan ligges på netværks laget.


IDS Rule frigivet

Jeg har frigivet en IDS rule der kan se når en server startes op. Selve infection delen på enheder sviger så meget at det kun er muligt at målrettet server delen pt. Dog kræver det at jeg får lidt mere data arbejde med, hvilket jeg pt arbejder på. Men ting tager tid.


 

Abnormal TTL values

14 Marts 2020  - Blog Post # 756

IcedID (Bokbot)
I forbindelse med en ret interesseant stykke malware, så jeg en meget gammel IDS rule trigger som jeg har skrevet for år tilbage og aldrig har publiceret. Det er kommet lidt i forlængelse med den seneste IcedID (BotkBot) jeg har skrevet. Jeg har ikke set denne rule trigger før nu (Som i aldrig set)

Jeg kan simpelthen ikke gennemskue hvad dette malware forsøger at opnå. Malwaren er kendt men ingen lader rigtig til at kommenterer denne TTL opførelse. (Virustotal)

Baggrund for IDS Rule
Denne skrev jeg engang på baggrund af en undersøgelse "Using abnormal TTL values to detect malicious IP packets" skrevet af Department of Computer Science and Engineering, Waseda University af Ryo Yamada and Shigeki Goto. Denne undersøgelse er skrevet helt tilbage i 2012. Denne handler om at benytte TTL til at identificere unormal trafik og der findes også angreb som eks "TTL Expiry Attack" som kan udnyttes rigtig fint i forbindelse med DDOS attacks.

TTL under 30.
I undersøgelsen "beviser" de at TTL under 30 er unormal opførelse. Derfor skrev jeg en IDS rule dengang der kiggede efter TTL under 30. Alle OS har deres default TTL values der benyttes og som er lidt det, der danner grundlag for undersøgelsen. Jeg tror ikke at billedet herunder er helt up to date længere. Så det er hvad det er.


Malware TTL
Kigger man på dette malware, så bruger det ICMP ping, hvor TTL forøges ved hvert forsøg på at pinge ud, indtil det får svar i den anden. Det eneste logiske jeg kan finde, er at tælle hops ud, for evt at kunne bruge dette til TTL Expire Attacks.

Følgende wireshark display filter kan benyttes
ip.ttl <30

IDS Rule frigivet
Jeg har opdateret denne rule til at kigge på TTL values som kommer indefra et netværk og er outbound med en TTL på under 30. Lige hvor meget malware jeg forventer at finde vil være minimum. Dog kan den finde tegn på Trojan-Banker.Win32.Cridex.

 

IcedID (BokBot) - Busted

 11 Marts 2020  - Blog Post # 755

IcedID (Bokbot)
IcedID alias Bokbot er et yderst kompliceret stykke malware. Det benytter bl.a. stenografi i billeder til payloads, Man in The Browser mm. Det er kendt som lidt af en hovedpine for mange at kunne opdage via netværkstrafik.

Ved at undersøge trafik fra flere års kampanger, er det lykkedes mig at finde en generic metode til at identificerer trafikken fra dette malware fra alle kampanger.


Wireshark
For at finde denne trafik med Wireshark kan man benytte følgende display filter. (Anbefaler dog man opretter en profil i Wireshark)
(((x509af.version == 2) && (tcp contains 30:03:01:01:ff)) && (ip.proto == 6)) && (tcp.srcport == 443)

Ved at tilføje et par enkelte Colums til Wireshark er det ingen sag at finde trafikken.

IDS Rules frigivet
Jeg har tidligere selv lavet IDS rules til at opdage IcedID, men de er typisk meget kortlivet. Jeg har testet den frigivet IDS rule op imod 1 TB trafik, uden dette har givet anledning til falske positiver. Høre gerne fra nogen såfremt den skulle give falske positiver. Er naturligvis lidt spændt på hvor lang tid der nu går, før de får rettes deres generic fejl.


 

Security Onion Updated

 03 Marts 2020  - Blog Post # 754

Opdateringer til security Onion
Har på det seneste fået lavet mange opdateringer til Security Onion. Det tæller nu 49 Dashboards og 407 objecter man kan bruge til søgninger. - Tjek det ud her.  Så nu er det klar til noget demo i Sverige i næste uge.

Windows Hardening med SRP - Ransomware

22 February 2020  - Blog Post # 753

Ransomware
16 September 2017 - Blog Post # 650 - skrev jeg om SRP rules og test med forskellige former for ransomware.
Mange bliver stadig ramt hårdt af ransomware, Senest ISS og før dem var det Demant og Mærsk.

Kigger man ind i maven på Windows systemer, så finde der en række at DIR's hvortil malware typisk bliver skrevet, og starter fra og endnu mere typiske placeringer hvor system variabler er mulige. Ved at kigge på hvor malware som de seneste Ryuk eksempelvis bliver skrevet til og køre fra, så kan man ved at brug SRP rules (Virker helt tilbage til windows XP systemer) kan man lave nogle default rules man bør benytte sig af. Disse kan forhindre rigtig meget malware i at køre, så det er ikke udelukkende til Ransomware. Men det kan hjælpe hvor bla Anti-virus fejler.

Kigger man på de seneste Ryuk tilfælde så ville 3 af disse SRP rules helt have forhindret det i at kunne køre og det deler placering med rigtig mange andre typer ransomware familier.

Bliv ikke nervøs
Mange jeg snakker med bliver nervøse over at komme til at breake stuff. Men malware er sjældent almindeligt stuff og ligger sig typisk ikke hvor de "almindelige applikationer ligger" For der kan det typisk ikke skrives til uden admin rettigheder osv. Så at brugere ikke har admin rettigheder er lige så vigtigt. Derudover holder jeg øje med hvad jeg forhindre i at køre med de SRP rules jeg benytter. Det gør jeg igennem et SIEM og kigger efter Event ID 866. Skal noget whitelistes og have lov til at fungere så tilføjer eller tilpasser  jeg det.

HINT HINT
- De frigivet dashboards jeg har liggende til Security Onion indeholder allerede dashboards til at kigge på SRP rules der trigger.

Man kan whiteliste admin account til at få lov til at køre filer. Det anbefaler jeg ikke. Det bør også gælde admins. Typisk sker der det at nogen tror de er super gode og kræver admin rettigheder igennem service desk, så kan man få det i x-antal timer, Så starter balladen...... Fordi brugeren ville jo kunne starte sit fantastiske word dokument de lige har fået via mail :-) Der kom jo en fejl.....hmmmmm BANG

Test Selv
Jeg har allerede testet dette i store netværk med stor success, (25K hosts) hvor man gik fra jævnligtt at have Ransomware til ALDRIG. Sådan har det være indtil i dag over en 4 årig periode.

Markeret med GRØN = Bør blive benyttet
Markeret med Gul = Kan blive benyttet


Jeg anbefaler klart deploy via GPO til en lille gruppe maksiner (hvad der nu passer) Hold øje med event ID 866 via SIEM dashboard og tilpas derefter.

Opmærksomhed her tak
Vær opmærksom på at SRP rules er hvad det er. Kan det bypasses...Absolut ja. En hacker med adgang til et system, kan helt bestemt sætte sig ned og undersøge hvorfra man så kan køre filer. Men så er han der allerede husk det. Hvad virker det så imod og hvorfor skal du benytte det ?

Fordi meget malware du vil møde i din dagligdag er lavet så det automatisk bare at køre. Hvorfor så ikke bare bruge SRP rules til at forhinde alle disse ting i at kunne køre helt automatisk (KillSwitch) Nu kan du så få den fordel at du også kan holde øje med de fil placeringer  via et SIEM.

Beskytter det imod al malware......NOP. De rules jeg har frigivet her har kun haft fokus på ransomware. Jeg testede på et tidspunkt hvor mange rules der skulle til for at dække en stor del af det mest kendte.. Så er vi oppe på lidt over 50 rules, og en maskine som mange ville få problemer med i dagligdagen. Derfor er SRP rules langt fra det bedste man kan benytte.

Det der burde blive benyttet
I virkeligheden burde man benytte sig af Whitelist på systemer som eks kunne være AppLocker eller andet tilsvarende, men mange lader åbenbart ikke til at magte denne opgave.  Dog vil jeg desuden til enhver tid foretrække Whitelist frem for Anti-Virus hvis jeg stod overfor det valg.

RanSIM
Testede en ransomware simulator fra KnowBe4. Først skulle jeg whiteliste at den overhovedet kunne køre, derefter fejlede alle dens test, grundet almindelig AV fra Microsoft. Da jeg fik slået AV fra, så den kunne starte, så fejlede alle andre test også (Spist af AV). Ved ikke hvor meget man skal stole på den type tools ??  Fik det aldrig til at virke.
De test jeg har lavet, har alle være med live ransomware..

Opdatering - 22-02-2020
Har netop lige set det "nye" Clop Ransomware som bennytter samme teknikker som Ryuk. Kroatiens største Olie firma er netop ramt lige nu. Her bliver payload startet fra %appdata%\Local\Temp\Low\9985.tmp.exe
SRP rule til at stoppe denne er er også på min liste.
%TEMP%\*\*.exe

 

QuakBOT (QBOT)

20 February 2020  - Blog Post # 752

QBOT
Jeg har brugt en del tid på at analysere Qbot infections helt tilbage fra 2016 til den seneste der blev udsendt i slutningen af Januar 2020. (PÆNT MANGE) Jeg forsøgte at finde en generisk metode til at finde hver gang der blev hentet payloads. Hvilket i store træk også lykkedes. Men aligevel ikke var helt perfekt, da jeg ikke kunne finde enkelte af de ældre kampanger......sucks.

Busted
Kigger man på selve C2 trafikken hvilke ser meget krypteret ud, så lykkedes det mig rent faktisk at finde en generisk detection der passede på alle kampanger nye som gamle. Her er det RIGTIG godt nar man har adgang til mere end et sample.

Trigger denne IDS rule er det 100% sikkert man er inficeret. Det viser sig rent faktisk at der findes nogle bytes der sendes hver gang en qbot forbinder sig tilbage til C2 serveren og ikke random informationer fra forskellige maskiner og hvilket er forskellig i næste alle kampanger.  

Det her får mig altid til at tænke.....Når man prøver at lave noget UNdetectable så har det typisk modsatte effekt.

Herunder kan du se noget detection på en typisk qbot kampange. Alt det der trigger her er ikke normal opførelse.
Viser også den nye detection på QuakeBot Flow samt noget XFIL detection jeg lavede tidligerer.

Wireshark display filters
(tcp contains 01:07:00:00:00:00:04:02:00:00) && (tcp.flags.str == "\xc2\xb7\xc2\xb7\xc2\xb7\xc2\xb7\xc2\xb7\xc2\xb7\xc2\xb7AP\xc2\xb7\xc2\xb7\xc2\xb7")



Happy hunting......

 

Security Onion updated

19 February 2020  - Blog Post # 751

Updated Security onion
I have been very busy, validating all the new stuff in this release of Security onion...I think i need a life soon. I will get outside and get some fresh air for a few days.

Just released update for the new Security Onion 16.04.6.4 running Elastic 6.8.6 You need to update to Winlogbeat 6.8.6.

I did en fresh install and all seams to work great on master servers and network sensors. Lots of new stuff in this release of Security Onion. Thanks for the great work...

Now supporting:
Security Onion - 16.04.6.4
Kibana 6.8.6 management
Winlogbeat - 6.8.6
Sysmon - 10.0.4.2

Happy hunting.....

.
 

SOC - Security Operations Center

17 February 2020  - Blog Post # 750

SOC - Mange kan sige ordet men ved ikke hvad det er og hvad det omhandler og kræver.
Jeg har skrevet et 27 siders dokument man kan læse, såfremt man gerne vil vide lidt mere om hvad det kræver at opbygge en SOC samt hvad kunder der ønsker at tilkøbe SOC ydelser bør være opmærksomme på.

Man bliver lidt trært....
Jeg er igennem tiden blevet lidt træt af alle dem der siger vi lige opbygger en SOC (Security Operations Center) Uden der er lavet invisterings planer og forankringer i top ledelsen samt placerer en SOC i en driftsorganisation. Som ikke sætter sig ind i hvilke systemer der bør være på plads før man overhovedet kan sælge noget.

Mange køber lige et par flad skærme hænger på væggen med strøm til der viser ofte ubrugelige og ligegyldige oplysninger. De laver et lokale der ser fint ud og er hammer mangelfuldt. Sidder 2 nyuddannet mand der kigger på hianden uden de rigtigt ved hvad de laver. SOC manageren er smuttet tidligt hjem for at hente børn uden nogen har taget over fordi der simplemt hen er for lidt personale.

Jeg håber jeg kan inspirere lidt til dem der gerne vil bygge en SOC til hvad de skal være opmærksomme på. Det er findes mange måder at gøre det på. Dem jeg har set der lykkes har nogenlunde fulgt det jeg allerede har skrevet om og dem jeg oftest ser fejle er SOC's der ønsker at være eksternt vendte og bygge det hele på kommercielle produkter.

Download SOC.PDF


 

AgentTesla and Trojan AZORult

11 February 2020  - Blog Post # 749

Hunting for AgentTesla and Trojan AZORult
Have been watching AgentTesla deploying Trojan AZORult for the last few days. AgentTesla can like many other malware frameworks deploy different kinds of malware. This time it is Trojan AZORult. Trojan AZORult is a complete trojan with password collectors from infected machines. It is pretty easy to defend aginst. BUT it all comes down to what the end user wants to click on......

Trojan AZORult (AngentTesla) uses mail as dropsites. It has been seen stealing information to systems like Statelite uplinks, Office365, Onedrive, Company websites, Facebook, Twitter, Private websites, Internal intranet websites, and others. It olso has a keyboard logger, witch is stealing all typed on the keeyboard and sending this to mail dropsite as well.

Here comes the fun part....Trojan AZORult i have seen on mail systems. The user of the AgentTesla allways send a test mail from there own system to see if it works. Often they don't delete this. (Pretty mutch busted).

Brian Krebs discovered who mr agent Tesla really is back in 2018

Here are some IOC's you can use.
Happy hunting.....

DNS
fentq[.]org - 89.208.196.16 Russian Federation (TROJAN AZORult)
This is a baby domain.

SNIP: Properly compromised user mail accounts. Many hundreds exists. (AgentTesla)
smtp[.]avastragroup[.]com
mail[.]canvanatransport[.]com
smtp[.]ge-lndustry[.]com
mail[.]wepmill[.]website
mail[.]greenwithoutborders[.]co[.]ke
webmail[.]zi-gem[.]com
smtp[.]alvinjay[.]com
smtp[.]emailsrvr[.]com
webmail[.]zi-gem[.]com
us2[.]smtp[.]mailhostbox[.]com

HTTP Header (TROJAN AZORult)
POST /x/index.php HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0b; Windows NT 5.1) (THIS IS A WINDOWS XP IE 6  User agent)
Host: fentq[.]org
Content-Length: 97
Cache-Control: no-cache

Detection
SRP rule needed (Kill switch)
%APPDATA%\Roaming\*\*.exe (TROJAN AZORult)
%UserProfile%\Desktop\*.exe (TROJAN AZORult and AgentTesla)

IDS RULES
ET Open
sid:2029141 - TROJAN AZORult v3.2 Server Response M3

NF - Networkforensic.dk rules
sid:5017403 - NF - Outbound mail connection sectup ESMTP (AgentTesla)
sid:5004012 - NF - POLICY - Windows XP making Internet connection - IE 6 - Company Policy Violation (TROJAN AZORult)

Microsoft AV detection name (TROJAN AZORult)
Trojan:Win32/Occamy.C


 

Sysmon and AppLocker

06 February 2020  - Blog Post # 748

Recommended information for learning about Sysmon and AppLocker
For all who is new to Sysmon, Elk or AppLocker, I can reccormend the following from Black Hills and the nice presentation by John Strand.

If you work with monitoring in a SOC and have a lot of event logs, you have to work with Elastic, witch i the right tool for the job. Security Onion is based on Elastic (ELK) and have allready been build for network traffic and combined with Winlogbeat and Syssmon it is perfect to get you started....and you have to learn all about this.



https://www.blackhillsinfosec.com/getting-started-with-sysmon/

https://www.blackhillsinfosec.com/webcast-implementing-sysmon-and-applocker/


Security Onion as a SIEM

30 Januar 2020  - Blog Post # 747

My first public release
You can now find my first release of dashboards, Winlogbeat with config and a renamed version of sysmon with a huge config file covering 95 MITRE Attacks alone.

And for the folks on the Security Onion user group...a BIG THANKS for direct feedback.

All released here..........



 

 

Security Onion as a SIEM

26 Januar 2020  - Blog Post # 746

Security onion med Sysmon og Winlogbeat integration
Er næsten færdig med alle de nødvendige dashboards og forwarding af event for at kunne leve op til NSA's krav omkring logning fra Windows systemer. Så nærmer mig en dag hvor jeg frigiver det hele som et samlet projekt alle vil kunne få glæde af. Dog er det allerede tilgængeligt såfremt du er på mail-listen som Security Onion tilbyder.

Filer er tilgængelige her. Password til filerne er via mail listen.
Dashboards Navigation
Install pack
Links removed  - Go here - Security Onion Tool



Hardware
Da dette er lavet som en "incident probe / analyse probe" man kan bygge til sig selv eller sin virksomhed. Så kan jeg anbefale at man benytter noget hardware med min 8 kerner på CPU'en, 1 til 60 TB storage. Man har fint plads med 8 TB på en 400M/bit internet forbindelse til over 1 uges trafik med fuld PCAP. MIN 12 GB Ram på en master server. Til sensors bør der være min 8 GB Ram.

10G netkort har jeg testet og de virker også fint. Har ikke økonomi til at købe kort der kan rulle mere end det, De fleste har ikke engang en Internet forbindelse der ruller så hurigt alligevel.... så 10G må være OK for nu.

Demo Film
Jeg har strikket en lille demo film sammen. Jeg viser et par af de dashboards man ville kunne få glæde af og hvad man kan forvente. DEMO DOWNLOAD Vær opmærksom på at projektet stadig ikke er færdigt. Men bliver det forhåbenteligt med lidt hjælp fra folkene bag Security Onion og hele deres bruger forum.
(Demo videoen er ændret til en mindre 30MB video -30-01-2020) - Links removed  - Go here - Security Onion Tool


MITRE Attack framework
MITRE bare vokser og voker. Den er nu oppe på 183 metodikker. Dog er jeg fulgt lidt med og er oppe på 95 beskrevet MITRE attack metodikker. Det er dog uden at jeg endnu har valideret hvad Security Onion i sig selv "out of the boks" dækker. Lige nu er der lavet 44 dashboards med tilhørende 352 visualizations.

 

Citrix ADC exploit

12 Januar 2020  - Blog Post # 745

Citrix ADC exploit exploits i stor stil. - CVE-2019-19781
Min anbefaling lige nu, er at tage Citrix ADC løsninger off-line, indtil man får en patch fra Citrix eller får styr på dem på anden vis. ....

Tjek desuden de her to paths på dit system:
ls /var/tmp/netscaler/portal/templates/
ls /netscaler/portal/templates/*.xml

Block evt følgende URLS med følgende i dem.
 "/../" og "/vpns/"

Demo
https://www.youtube.com/watch?v=b02Sj2UDpYE

123....så har man root password.....

Anbefalet at lige gennemse
https://www.youtube.com/watch?v=kpOK_S7Z-K4

Forventet patch frigivelse
Der går simpelt hen for lang tid før denne her bliver fikset og det er med 100% garanti man så er blevet hacket inden da, hvis man ikke allerede er blevet det og hvem har noget vigtigt liggende på Citrix !!!!!

IMPORTANT UPDATE: CITRIX announced that a patch will be released on January 20th for Citrix ADC 11/12 and 13. Version 10 will have to wait until January 31st. (https://support.citrix.com/article/CTX267027)

Anbefalet Mitigering
https://support.citrix.com/article/CTX267679



IDS Rules frigivet
Jeg har tilpasset en frigivet IDS rule. Men vær meget opmærksom på at exploitet i virkeligheden forventes at blive udnyttet over HTTPS og ikke HTTP. Desuden er denne kun målrettet imod det frigivet exploit fra TrustedSec.

Denne kigger heller ikke efter alle de forskellige payloads som ryger med pt. som er simple bagdøre lige nu. Men det forventer jeg bliver ændret meget hurtigt til alt muligt andet.
 

OPDATERING - Lidt time frame information:  Har man ikke mitigeret fra den 8 JAN 2020 hvor jeg har set de første scanninger imod systemer og frem skal man forvente at man er blevet hacket fra d 11 JAN 2020 med 99.9% sikkerhed. Denne dag har jeg set hacket systemer fra mange forskellige dele af Danmark der storet set er hacket samme dag op til flere gange via Citrix sårbarheden. Alle jeg har set har fået nuppet config filen.

Det "smukke" er jo ved denne såarbarhed. At reinstallere man bare sit system og efterfølgende patcher / mitigerer, så har man ikke set om config filen fra systemer allerede er nuppet af hackerne. Det betyder at hackerne nu kan cracke hashes fra config filen og bare efterfølgende logge ind som en almindelig bruger via AD credentials. Man kan dog være mere sikker imod denne del såfremt man benytter 2FA.  Har man ikke det skal alle fra AD grupper der giver citrix adgang have reset af password og husk at skifte root password til Citrix enheden. MEN HUSK at det kan være en hacker der kommer og logger på der så bliver mødt med et ønske om password skift........Man skal så til at tjekke ip adresser hvorfra der bliver logget ind. Det er dog kun en marginal bedre validering, da en hacker også kan logge ind fra eks danske ip adresser. Nogen fra DK-CERT har ikke lige helt forstået det her lader det til !!!! Det kunne også være at de skulle tjekke de forskellige nationale CERT teams og deres anbefalinger inde de rynker på næsen.

OBS ! - Så tjek hvilke brugere der i den off loaded config og hvilke brugere der lå hashes til. Det er dem der skal have et reset af password og dem der kan være de "farlige". Her har man kun et time span på 36 timer indtil der bliver foretaget en cleanup på systemet af malwaren. Efter 36 timer er all bets off.

De fleste jeg har set har netop bare reinstalleret og mitigeret uden at gøre mere. (Forvent uventet gæster......)

 

Microsoft Message Analyzer

5 Januar 2020  - Blog Post # 744

Microsoft Message Analyzer
Tidligerer har jeg benyttes mig af Microsoft Message Analyzer. Denne er dog desværre gået på pension. Dog er det stadig muligt at benytte sig af en lille converter til ETL filerne. Derved kan man stadig få trukket trafik data ud. Dette er meget nyttigt i forensic sager med begrænset muligheder for installation af tools direkte på systemer.




etl2pcapng
Dette tool kan hentes herfra. - https://github.com/microsoft/etl2pcapng


 

Security Onion as a SIEM

 28 December 2019  - Blog Post # 743

Security Onion as a SIEM
 Igennem de sidste par måneder har jeg desværre ikke haft meget tid til IDS rule writing. Dette er bestemt ikke uvilje for jeg har rigtig meget materiale liggende jeg kunne gå i gang med.

Skarpt fokus
Jeg har været skarpt fokuseret på at få gjort en "Incident probe" (kalder jeg det) klar. Den bygger på en Security Onion, der så bygger på Elastic med Kibana osv.Jeg har lavet en ret omfattende Sysmon integration samt opsamling af Windows events, med yderligerer et par tusinde IDS rules jeg selv har lavet og intigreret ind i denne SO. Den bygger desuden på korrekt opsamling af logs fra Windows systemer samt understøttelse af så mange MITRE attack metodikker som muligt. Så alene nedtunungen af Windows event logs har taget ligt tid, da jeg ikke vil opsamle ALT hvad en Windows maskine kan sende hvilket er ret omfattende.

Det gør samlet at jeg får fuld netværks trafik samt logs fra alle endpoints hvilket gør security Onion meget stærk sammen med alle de ting som Security Onion i forvejen kan "out of the box"  Desuden er Incident proben nem at flytte rundt på og kan deployes på ganske kort tid. Det bevirker at man hurtigt kan få øjne på/i et netværk og systemer i en infrastruktur hvor der meget ofte slet ikke er opsat noget logopsamling af nogen art. Sammenholdt med at man kan deploye sensors rundt i et netværk gør at et team af analytikkerer hurtigt kan komme igang med at arbejde på det opsamlet data.

Tid tid og atter tid til test.
Det der har taget tid for mig at få lavet, er de mange test og visualiseringer med dashboards osv. de skal til før end den giver mening. Pt har jeg fremtillet godt 40+ nye dashboards til SO Kibana. Jeg har lavet alt arbejdet selv og det har taget mig mange dage og nætterr at få det gjort,  Men må sige at jeg nu har et Security Onion setup på steorider, der desuden også understøtter og kører distribueret sensors og virker som et fuldt SIEM system.

Den dækker pt. alene ca 85 MITRE attack metodikker ud af de ca 130 der findes. Den vil aldrig kunne dække alle, men er egentelig rigtig godt for et gratis produkt med lidt tryllestøv oven på. Den vil naturligvis aldrig kunne dække alle MITRE attack metodikker, da det jo i praksis ikke kan lade sig gøre.



Test med Virus og rigtig meget forskelligt malware
Efterhånden som jeg har bygget den, har jeg haft fokus på at kunne finde tegn på virus og malware hacker angreb osv. og hvor har jeg "brændt mange pc'er af med malware i den seneste tid" Her må jeg sige at den gør en rigtig god figur. Alene Sysmon implementeringen er yderst stærk. Man kunne her ønske sig at Sysmon var en fast del af Windows. Alt hvad jeg har kastet efter Incident proben indtil nu, har jeg hele tiden kunnet finde tegn på er sket.

Frigivelse til public
Jeg forventer at jeg i løbet af starten af det nye år kan frigive små dele af projektet igennem Security Onion.

Andre SIEM systemer
Jeg har igennem tiden prøvet de fleste SIEM løsninger, og hver har de deres sexet ting de kan. Men der hvor de fleste fejler er håndteringen af mængden af data. Søgninger tager alt for lang tid, lige så snart der kommer store mængder data til disse, hvilket der næsten altid gør på et SIEM system.

Så vores valg af Elastic, der kan håndtere de store mængder data og hvor søgninger stadig kan laves hurtigt, har gjort Elastic til det helt rigtig valg hvor alle de andre fejler bragt i min/ vores optik. Bla er Elastic er extremt nem at "size op" uden man skal tilkøbe systemer i form a flere servers til 500k stykket. Med Elastic kan man nøjes med noget der ligner størrelsen på en laptop i både pris og data kapacitets muligheder og ydeevne.

Med SIEM systemer er det netop en MEGET vigtig faktor, at søgninger kan foretages hurtigt og at man ikke skal vente resultater når det hele brænder. Er et SIEM system langsomt fra starten, er det i min optik ubruligt fra starten af uanset hvor sexet det end måtte være.

 

Blog posts

Alt hvad jeg har skrevet om igennem 2020